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Abstract 

The  research  presented  in  this  document  defines  a  methodology  for  automatically  ex¬ 
tracting  functionally  equivalent  object-oriented  designs  from  legacy  imperative  programs. 
The  Parameter-Based  Object  Identification  (PBOI)  methodology  is  based  on  fundamen¬ 
tal  ideas  that  relate  programs  written  in  imperative  languages  such  as  C  or  Cobol  to 
objects  and  classes  written  in  object-oriented  languages  such  as  Ada  95  or  C-f- 1-.  The 
fundamental  thesis  that  defines  the  PBOI  methodology  is  that  object  attributes  manifest 
themselves  in  imperative  subprograms  as  data  items  passed  between  subprograms.  The 
PBOI  methodology  converts  each  subprogram  in  an  imperative  design  into  a  class  and  a 
method  that  implements  the  subprogram.  During  this  process  duplicate  classes  are  elimi¬ 
nated,  duplicate  objects  are  identified,  and  overlapping  classes  are  merged  into  one  class. 
Transformations  have  been  developed  that  formalize  the  PBOI  methodology  and  a  formal 
proof  is  provided  showing  the  extracted  object-oriented  design  is  functionally  equivalent 
to  the  legacy  imperative  system.  To  focus  the  task  of  re-engineering,  generic  models  of 
imperative  programming  languages  and  object-oriented  programming  languages  have  been 
developed.  The  Generic  Imperative  Model  (GIM)  is  programming  language  independent, 
programming  construct  independent,  and  canonicalizes  simulated  control  flow  constructs. 
Formal  definitions  for  the  semantics  of  each  GIM  construct  have  been  defined  using  the 
weakest  precondition  notation.  The  Generic  Object-Oriented  Design  model  (GOM)  is  also 
programming  language  independent  and  programming  construct  independent.  Formal  def¬ 
initions  for  the  semantics  of  each  GOM  construct  have  also  been  defined  using  the  weakest 
precondition  notation.  The  formal  tranformations  convert  imperative  subprograms  repre¬ 
sented  in  the  Generic  Imperative  Model  into  classes  and  objects  represented  in  the  Generic 
Object-Oriented  Design  Model.  A  taxonomy  of  imperative  subprograms  has  also  been 
developed  which  classifies  all  imperative  subprograms  into  one  of  six  categories.  A  proof 
of  concept  prototype  has  been  developed  and  a  3000-line  FORTRAN-77  system  has  been 
converted  to  an  object-oriented  design  as  a  feasibility  demonstration. 
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Extracting  Functionally  Equivalent 
Object-Oriented  Designs  from 
Legacy  Imperative  Code 


I.  Introduction  and  Background 

1.1  Introduction 

1.1.1  Overview.  The  object-oriented  paradigm  with  its  promise  of  re-usability, 
extensibility,  and  maintainability  has  great  appeal  to  organizations  with  aging  legacy  sys¬ 
tems.  Legacy  systems  are  often  complex,  unstructured,  and  include  no  documentation. 
Making  even  the  smallest  change  to  a  legacy  system  often  creates  unpredictable  side- 
effects.  Legacy  systems  are  valuable  assets  to  an  organization  and  should  be  preserved, 
not  thrown  away  [49].  Re-engineering  imperative  legacy  systems  into  object-oriented  sys¬ 
tems  provides  a  way  for  organizations  to  modernize  their  aging  systems  without  losing  the 
investment  that  these  systems  represent  [50,67]. 

The  research  fields  of  re-engineering  and  reverse  engineering  have  recently  emerged 
within  the  field  of  software  engineering.  The  goal  of  software  engineering  is  to  improve 
the  products  and  practices  used  to  develop  software.  However,  the  majority  of  the  soft¬ 
ware  development  effort  is  spent  on  maintaining  legacy  systems  as  opposed  to  developing 
new  systems  [61].  Boehm  [8]  estimates  the  proportion  of  resources  and  time  devoted  to 
maintenance  ranges  from  50%  to  80%.  The  implication  is  that  in  order  to  improve  the 
software  development  process,  the  software  maintenance  process  must  be  examined.  Since 
maintaining  an  object-oriented  system  is  inherently  easier  than  maintaining  an  impera¬ 
tive  system  [32,33],  re-engineering  legacy  code  to  the  object-oriented  paradigm  improves 
the  maintenance  process.  Furthermore,  re-engineering  to  the  object-oriented  paradigm  is 
desirable  to  organizations  because  it  improves  the  overall  software  development  process. 

The  research  presented  in  this  document  defines  a  methodology  for  automatically 
identifying  objects  from  legacy  imperative  programs.  The  Parameter- Based  Object  Identi- 
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fication  (PBOI)  methodology  is  based  on  fundamental  ideas  that  relate  programs  written 
in  imperative  languages  such  as  C  or  Cobol  to  objects  and  classes  written  in  object-oriented 
languages  such  as  Ada  95  or  C-|-+.  Transformations  have  been  developed  that  formalize 
the  methodology  and  a  proof  is  provided  showing  the  extracted  object-oriented  design  is 
functionally  equivalent  to  the  legacy  system.  To  focus  the  task  of  re-engineering,  generic 
models  of  imperative  programming  languages  and  object-oriented  programming  languages 
have  been  developed.  The  formal  transformations  convert  imperative  subprograms  repre¬ 
sented  in  the  imperative  model  into  classes  and  objects  represented  in  the  object-oriented 
model.  A  taxonomy  of  imperative  subprograms  has  also  been  developed  which  classifies 
all  imperative  subprograms  into  one  of  six  categories. 

The  remainder  of  this  chapter  defines  re-engineering  terms  in  Section  1.2  and  presents 
related  work  in  the  field  of  re-engineering  in  Section  1.3.  A  summary  of  research  contribu¬ 
tions  is  provided  in  Section  1.5  and  brief  descriptions  of  the  following  chapters  is  presented 
in  Section  1.6.  The  author  assumes  the  reader  has  fundamental  knowledge  about  both  the 
imperative  paradigm  [16]  and  the  object-oriented  paradigm  [62]. 

1.2  Definitions 

The  following  definitions  are  provided  for  the  terms  re-engineering,  reverse  engineer¬ 
ing,  and  program  understanding. 

1.2.1  Re-Engineering.  According  to  Chikofsky  [13], 

Re-engineering  is  the  examination  and  alteration  of  a  subject  system  to  recon¬ 
stitute  it  in  a  new  form  and  the  subsequent  implementation  of  the  new  form. 

Typically,  a  system  being  re-engineered  is  written  in  an  outdated  programming  language 
or  built  specifically  for  an  outdated  hardware  platform.  Computer  systems  that  were 
built  many  years  ago  and  have  undergone  several  maintenance  modifications  often  become 
what  are  known  as  legacy  systems.  A  legacy  system  is  hard  to  maintain  because  of  the 
lack  of  knowledge  about  the  system  and  because  of  the  side  effects  when  making  even  a 
simple  change  to  the  system.  The  computer  program  in  a  legacy  system  is  called  legacy 
code.  Re-engineering  often  focuses  on  revamping  legacy  systems  using  new  programming 
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Figure  1  Re-Engineering  Process 


paradigms,  languages,  or  hardware  platforms.  Figure  1  shows  a  generalized  view  of  the 
process  of  re-engineering  legacy  code  as  developed  by  Byrne  [12].  In  order  to  do  effective 
re-engineering,  the  legacy  code  must  be  expressed  at  a  higher  level  of  abstraction  than  the 
programming  language  in  which  it  was  written  [75].  This  process  of  expressing  the  legacy 
code  in  a  higher  level  of  abstraction  is  reverse  engineering  as  shown  on  the  left  hand  side 
of  Figure  1.  The  different  levels  of  abstraction  in  re-engineering  include  implementation, 
design,  and  requirements  specifications. 

Legacy  code  can  be  re-engineered  at  each  of  these  levels  of  abstraction.  At  the 
implementation  level,  it  is  possible  to  re-code  a  program  from  one  programming  language 
to  another.  At  the  design  level,  it  is  possible  to  re-design  a  program  changing  the  design 
of  the  legacy  code  into  a  design  for  the  target  system.  At  the  requirements  specification 
level,  it  is  possible  to  re-specify  the  requirements  for  a  program.  Each  of  these  processes  is 
discussed  in  more  detail  in  Section  1.2.2. 
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Once  these  transformations  are  done  at  the  different  levels  of  abstraction,  forward 
engineering  can  be  used  to  build  the  target  system  in  the  new  paradigm  or  language.  Re¬ 
engineering  is  the  overall  process  of  reverse  engineering  followed  by  forward  engineering. 
This  process  does  not  require  the  target  system  to  be  functionally  equivalent  to  the  legacy 
system. 

. . . . ill . .  . . . . . . . . . . . . .  . . . . . ^ ' 'v;  . . . . . . . 


Figure  2  Reverse  Engineering  Process 

1.2.2  Reverse  Engineering.  Figure  2  shows  the  process  of  reverse  engineering 
in  more  detail.  To  abstract  legacy  code,  implementation  information  must  be  available. 
This  is  typically  the  programming  language  code  such  as  FORTRAN  or  Cobol  code.  It  is 
possible  to  restructure  the  implementation  information  during  reverse  engineering  without 
re-engineering  the  legacy  code  to  a  new  target  system.  A  restructuring  at  the  implemen¬ 
tation  level  could  possibly  include  eliminating  GOTO  statements  from  the  legacy  code. 

The  process  of  reverse  design  abstracts  the  implementation  information  up  to  the 
design  level.  This  process  extracts  information  such  as  structure  charts  showing  the  calling 
hierarchy  of  the  legacy  code,  data  flow  diagrams  showing  the  flow  of  data  in  and  between 
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legacy  code  routines,  or  control  flow  diagrams  showing  the  flow  of  control  for  the  legacy 
code.  Restructuring  can  also  be  done  at  the  design  level  without  doing  re-engineering.  For 
example,  the  structure  chart  could  be  reorganized  to  improve  the  number  of  connections 
between  different  legacy  code  routines,  i.e.,  improve  the  coupling  [64]  between  routines. 

The  design  level  information  is  abstracted  up  to  the  requirements  specification  level 
by  the  reverse  specification  process.  This  process  extracts  the  specifications  for  the  legacy 
code  from  the  design  information.  Restructuring  can  also  be  done  at  this  level  of  ab¬ 
straction.  For  example,  the  specifications  could  be  split  apart  and  reorganized  to  improve 
understandability. 

Often  in  reverse  engineering,  a  system  undergoes  a  program  understanding  process 
in  order  to  create  a  more  robust  and  understandable  abstraction  of  the  program.  Pro¬ 
gram  understanding  is  a  special  form  of  reverse  engineering.  An  overall  view  of  program 
understanding  is  presented  in  the  following  section. 

1.2.3  Program  Understanding.  This  section  describes  the  current  cognitive  sci¬ 
ence  notion  of  human  program  understanding  as  found  in  Tiemens  [73] .  Figure  3  shows  an 


Figure  3  Program  Understanding  Theory 


overall  notion  of  how  humans  understand  programs.  The  knowledge  base  stores  concepts  the 
person  already  understands  such  as  analysis  and  design  techniques,  programming  architec¬ 
tures,  specific  algorithms,  and  specific  programming  language  constructs.  This  knowledge 
ranges  from  abstract  notions  such  as  architecture  to  concrete  notions  such  as  assignment 
statements  in  FORTRAN. 
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The  legacy  code  is  the  programming  language  code  the  person  is  trying  to  understand. 
This  code  is  typically  in  the  form  of  a  listing  the  person  can  examine.  There  is  typically 
no  pre-processing  of  this  code  before  the  person  examines  it. 

The  assimilation  process  involves  the  person  looking  at  the  code  and  trying  to  find 
concepts  in  the  knowledge  base  implemented  in  the  legacy  code.  This  process  is  aptly 
called  “assimilation”  because  the  person  is  trying  to  fit  the  processing  being  done  by  the 
legacy  code  into  the  knowledge  he  or  she  already  has  in  the  knowledge  base.  The  process 
builds  new  knowledge  that  is  linked  to  the  knowledge  base  and  stored  in  the  mental  model. 

The  mental  model  is  a  series  of  links  created  in  the  assimilation  process  by  the  person 
understanding  the  legacy  code.  The  mental  model  is  the  person’s  understanding  of  how  the 
processing  of  the  legacy  code  fits  into  what  he  or  she  already  knows.  The  links  between  the 
knowledge  base  and  the  legacy  code  are  rich  semantic  links  from  what  was  known  before 
to  what  is  being  understood  now.  Understanding  is  a  process  of  recognition,  abstraction, 
assimilation,  and  storage  [73]. 

This  overall  view  of  program  understanding  is  by  no  means  complete  because  the 
area  of  program  understanding  is  an  open  field  in  cognitive  science.  However,  the  ideas 
presented  here  are  an  adequate  presentation  of  the  current  literature  in  this  field. 

1.3  Related  Work 

This  section  reviews  previous  work  in  the  area  of  reverse  engineering.  This  review 
includes  significant  contributions  in  program  understanding,  extracting  software  architec¬ 
tures,  extracting  objects,  and  maintaining  functional  equivalence.  The  overall  landscape  of 
these  contributions  is  presented  below  followed  by  detailed  descriptions  of  selected  systems. 

Research  contributions  thus  far  in  the  area  of  reverse  engineering  can  be  loosely 
categorized  based  on  three  criteria: 

Knowledge  The  level  of  the  knowledge  extracted  from  the  legacy  code. 

Strategy  The  approach  used  for  reverse  engineering. 

Goal  The  end  result  or  product. 
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Knowledge 


Strategy 

Figure  4  Reverse  and  Re-Engineering  Systems 


Figure  4  shows  these  criteria  on  three  axes.  The  axis  labeled  Knowledge  shows 
the  different  levels  of  knowledge  that  can  be  extracted.  Language  knowledge  is  low-level 
knowledge  about  a  programming  language  such  as  FORTRAN  or  Cobol.  Programming 
knowledge  includes  knowledge  about  common  ways  to  implement  algorithms  such  as  sorting 
or  searching.  Design  knowledge  is  knowledge  about  the  architecture  or  overall  design 
of  a  legacy  code.  Domain  knowledge  is  knowledge  about  the  application  domain  being 
implemented  by  the  legacy  code.  The  axis  labeled  Strategy  shows  the  different  strategies 
used  in  reverse  engineering.  Plan  Recognition  strategies  rely  on  pre-defined  plans  or  cliches 
that  describe  the  concepts  to  be  recognized.  Data  Driven  strategies  rely  on  information 
from  the  legacy  code  such  as  data-flow,  control-flow,  and  program  slices  in  order  to  extract 
knowledge.  Informal  Information  strategies  extract  information  from  documentation  and 
comments  from  the  legacy  code. 
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The  axis  labeled  Goal  shows  the  goals  of  the  reverse  engineering  systems.  Program 
Understanding  systems  produce  a  mapping  between  concepts  and  the  legacy  code  which 
represents  an  understanding  of  the  legacy  code.  The  Architecture  goal  refers  to  systems  that 
recover  the  architecture  used  in  the  legacy  code.  This  ranges  from  low-level  products  such 
as  module  interconnection  diagrams  to  high-level  products  such  as  recognizing  a  client- 
server  architecture.  The  Objects  goal  refers  to  systems  that  recover  objects  and  classes 
from  the  legacy  code.  Systems  in  this  category  recover  as  many  objects  as  possible,  but 
are  not  focused  on  duplicating  the  functionality  of  the  legacy  code  with  these  objects.  The 
Functionally  Equivalent  Objects  systems  recover  objects  and  classes  with  the  specific  goal 
of  maintaining  the  functionality  of  the  legacy  code. 

1.3.1  Plan  Recognition  Systems.  Work  in  the  area  of  program  understanding  has 
been  dominated  thus  far  by  the  plan  (or  cliche)  recognition  systems  [28,48,51,60,70].  Plan 
recognition  systems  were  inspired  by  forward  engineering  systems  based  on  plans  including 
the  Programmer’s  Apprentice  [56-59,74].  Plan  recognition  systems  aid  in  understanding 
legacy  code  by  matching  the  code  to  a  pre-defined  plan  with  concepts  and  constraints 
between  the  concepts.  Once  the  plan  is  found  in  the  code,  the  concept  being  represented 
by  the  plan  is  considered  to  be  understood.  These  plans  can  be  organized  into  a  hierarchy 
representing  low-level  programming  knowledge  up  to  high-level  domain  knowledge. 

Figure  4  shows  where  plan  recognition  systems  fit  in  the  overall  landscape  of  re¬ 
engineering  systems.  As  shown  in  the  figure,  some  plan  recognition  systems  (Wills,  Ning, 
etc.)  can  recognize  domain  knowledge  while  others  (Hartman  and  Johnson)  recognize 
design  knowledge.  The  goal  of  plan  recognition  systems  has,  to  this  point,  been  program 
understanding. 

1.3. 1.1  Rich’s  Work  [60].  The  Recognizer  system  built  by  Rich  and  Wills 
automatically  finds  all  occurrences  of  a  concept  in  a  program.  This  system  relies  on  the 
idea  of  cliches  for  concept  recognition  and  uses  the  plan  calculus  [57]  to  represent  programs 
and  cliches.  The  Recognizer  builds  a  hierarchical  representation  of  the  concepts  it  finds 
in  the  programs  and  associates  a  natural  language  description  with  each  of  the  concepts 
recognized. 
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Rich  addresses  five  problems  in  legacy  code  that  are  handled  by  using  cliches  to 
represent  knowledge: 

Syntactic  variation  The  same  net  flow  of  data  and  control  can  be  achieved  in  many 
ways. 

Non-contiguousness  Parts  of  a  cliche  can  be  scattered  through  the  program  text; 
they  do  not  have  to  be  contiguous. 

Implementation  variation  An  abstraction  can  be  implemented  in  many  ways. 

Overlapping  implementation  Program  optimization  can  merge  the  implementa¬ 
tions  of  distinct  abstractions. 

Unrecognizable  code  It  is  hard  to  find  “good”  concepts  in  code  if  the  code  was 
not  built  from  a  template  such  as  a  cliche. 

The  Recognizer  system  transforms  programs  into  the  plan  calculus  to  overcome  the 
problems  of  syntactic  variation  and  non-contiguousness.  The  Recognizer  also  includes  a 
hierarchy  of  cliches  represented  in  the  plan  calculus.  By  representing  both  programs  and 
cliches  in  the  plan  calculus,  Rich  has  made  the  matching  process  much  simpler.  The  process 
of  matching  cliches  to  programs  is  treated  as  a  graph  parsing  problem.  The  Recognizer 
demonstrates  understanding  of  the  program  by  producing  documentation  automatically. 
It  does  this  by  using  generic  natural  language  templates  stored  with  each  cliche  and  filling 
in  the  appropriate  fields  from  the  code.  The  documentation  has  an  artificially  formal  flavor 
to  it,  but  demonstrates  shallow  understanding  of  design  decisions  made  in  producing  the 
code. 

Overall,  Rich’s  research  raises  some  important  issues.  First,  for  program  under¬ 
standing,  there  must  be  some  representation  of  the  concepts  to  be  recognized.  Second, 
the  representation  of  concepts  must  be  compatible  with  the  representation  of  the  program. 
Using  the  plan  calculus  to  represent  both  the  program  and  the  cliches  is  a  good  com¬ 
mon  representation  for  the  Recognizer.  Using  the  plan  calculus  overcomes  the  problem  of 
syntactic  variation  and  non-contiguousness.  It  also  casts  the  problem  as  a  graph  parsing 
problem  which  taps  into  a  rich  resource  for  problem  solving.  Rich  calls  this  approach  a 
representation  shift. 

1.3. 1.2  Ning’s  Work.  Ning  [26]  developed  the  Program  Analysis  Tool 
(PAT)  to  aid  program  understanding.  The  system  uses  a  plan  hierarchy  and  rule-based 
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inferencing  system  to  recognize  low-level  constructs  in  the  code  and  combine  these  to 
form  higher-level  abstract  concepts.  Ning  [39]  discusses  automating  the  process  of  concept 
recognition  by  transforming  programs  to  different  levels  of  abstraction: 

Text-level  transformations  treat  a  program  as  a  sequence  of  characters  and  trans¬ 
form  the  program  using  character  substitution. 

Syntactic-level  transformations  treat  programs  as  abstract  syntax  trees  and  trans¬ 
form  programs  using  rules  about  the  abstract  syntax  descriptions. 

Semantic-level  transformations  add  meaning  to  the  syntax  of  programs  and  trans¬ 
form  programs  using  the  semantic  information  found  in  control  flow  and  data  flow 
diagrams. 

Concept-level  transformations  rely  on  knowledge  of  programming,  problem  solving, 
and  application  domains  to  transform  programs  at  the  conceptual  level. 

Ning  [39]  also  discusses  the  general  problem  of  concept  recognition.  Programs  contain 
many  different  kinds  of  information  which  can  be  divided  into  language  concepts  and  ab¬ 
stract  concepts.  Language  concepts  are  the  low-level  syntactic  programming  concepts  from 
the  legacy  code.  They  include  modules,  language  statements  and  other  concepts  defined 
by  the  programming  language  syntax.  Abstract  concepts  refer  to  language-independent 
concepts  such  as  programming  concepts  and  problem  solving  methods  such  as  searching 
and  sorting. 

A  programming  language  compiler  recognizes  language  concepts  and  builds  them 
into  an  Abstract  Syntax  Tree  for  a  program.  To  recognize  abstract  concepts,  a  concept 
classification  hierarchy  called  a  concept  model  is  used  to  define  the  knowledge  to  be  rec¬ 
ognized.  This  model  will  not  be  complete  since  abstract  theories  of  general  programming 
are  hard  to  develop.  Thus,  a  partial  recognition  of  the  program  is  possible.  This  means  it 
may  not  be  able  to  recognize  the  program  as  representing  a  single  concept,  but  it  may  be 
possible  to  recognize  islands  of  concepts  in  the  program.  The  concept  model  also  defines 
the  attributes  of  the  concepts  to  be  recognized.  Ning  develops  the  idea  of  a  plan  to  rep¬ 
resent  a  concept.  A  plan  contains  components  (or  sub-concepts)  of  the  concept  and  the 
constraints  between  the  sub-concepts.  This  information  is  encoded  in  the  form  of  concept 
recognition  rules.  Plans  represent  the  abstract  concepts  to  be  recognized,  and  through  the 
constraints  of  the  plans,  they  represent  how  these  concepts  will  be  recognized. 
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Ning’s  work  is  important  because  it  exemplifies  plan  recognition  systems.  In  any 
program  understanding  system,  all  levels  of  abstraction  need  to  be  recognized.  Ning  shows 
how  a  hierarchy  of  concepts  can  be  recognized  using  a  hierarchy  of  plans.  Ning’s  work  was 
the  basis  for  continued  work  in  plan  recognition  by  Letovsky  [41],  Quilici  [51],  Chin  [52], 
and  others  as  discussed  in  the  next  section. 

1.3. 1.3  Other  Plan  Recognition  Systems.  The  Cognitive  Program  Under¬ 
stander  (CPU)  system  by  Letovsky  [41]  uses  plans  as  correctness  preserving  transforma¬ 
tions  for  rewriting  programs  into  semantically  equivalent  yet  more  abstract  representations. 
Quilici  [51]  enhanced  Ning’s  plan  hierarchy  to  include  indices  into  the  plan  hierarchy,  a 
specialization  mechanism,  and  links  to  other  related  plans.  These  improvements  were  in¬ 
tended  to  speed  up  the  plan  recognition  process.  The  DECODE  system  from  Chin  [52] 
builds  up  a  concept  base  through  interaction  with  the  programmer.  DECODE  uses  an 
enhanced  plan  recognition  system  to  recognize  as  much  of  the  legacy  code  as  possible.  It 
increases  understanding  of  the  program  by  allowing  the  programmer  to  enter  new  con¬ 
ceptual  design  primitives  and  linking  them  to  the  program.  The  UNPROG  system  by 
Hartman  [28]  uses  plans  to  recognize  control  designs  such  as  read-process  loops  in  Cobol 
programs.  The  PROUST  system  from  Soloway  and  Johnson  [70]  uses  plans  in  a  top-down 
method  in  order  to  understand  novice  programmer’s  code. 

Overall,  the  plan  recognition  systems  are  limited  by  the  number  of  plans  required  to 
fully  understand  legacy  code.  If  the  exact  plan  that  represents  the  concept  being  imple¬ 
mented  by  the  legacy  code  is  not  present  in  the  plan  hierarchy,  the  plan  recognition  system 
is  not  able  to  understand  the  legacy  code.  This  implies  large  plan  hierarchies  are  required 
to  understand  even  simple  programs.  The  plan  recognition  process  does  not  scale  up  well 
to  large  production- level  legacy  code.  Quilici  and  Chin  write  [52]: 

Applying  this  paradigm  to  reverse  engineering  real-world  legacy  systems  is 
problematic,  as  it  appears  to  require  enormous  libraries  of  code  patterns,  relies 
on  program-understanding  algorithms  that  are  not  guaranteed  to  scale,  and  fails 
completely  on  existing  idiosyncratic  code  that  does  not  fit  well  into  patterns  [17, 
40,69]. 

The  plan  recognition  systems  suffer  from  problems  that  limit  their  applicability  to 
real-world  systems  [52].  The  methodology  presented  in  this  document  does  not  use  libraries 
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of  code  patterns.  Instead,  it  uses  a  data-driven  approach  similar  to  the  systems  described 
in  the  next  section. 


1.S.2  Data-Driven  Systems.  Plan  recognition  systems  are  contrasted  with  the 
data-driven  systems  as  shown  in  Figure  4.  Data-driven  systems  do  not  rely  solely  on 
the  process  of  matching  plans  for  recognizing  concepts  in  legacy  code.  Some  data-driven 
systems  use  low-level  knowledge  about  the  legacy  code  to  limit  the  amount  of  code  being 
considered  when  matching  plans  to  the  code.  In  general,  data-driven  systems  use  data¬ 
flow  and  control-flow  dependencies,  program  slicing,  and  definition/usage  information  to 
extract  design  and  programming  knowledge.  The  data-driven  systems  have  varying  reverse 
engineering  goals  including  extracting  architectures  and  objects.  The  following  sections 
present  relevant  data-driven  systems. 

1.3.2. 1  Newcomb’s  Work  [47j.  This  section  describes  Newcomb’s  work  on 
recovering  functionally  equivalent  collections  of  objects  from  legacy  code.  The  following 
terms  are  defined  by  Newcomb  and  help  explain  the  process. 

Scope  analysis  relates  the  occurrence  of  a  variable  to  its  declaration. 

Program  unit  analysis  describes  the  signature  of  routines,  i.e.,  the  number,  order, 
and  type  of  parameters  for  all  routine  declarations  and  invocations. 

Collision  former  is  a  unique  template  of  a  data  structure  based  on  record  length, 
field  offset,  field  length  and  field  type. 

Alias  analysis  is  the  process  of  finding  the  names  of  the  records  and  subfields  in 
legacy  code  that  match  the  collision  former. 

Alias  map  represents  a  relation  whose  domain  is  a  collision  former  and  whose  range 
is  a  set  of  records  that  match  the  collision  former.  The  criteria  for  matching  the 
collision  former  can  be  changed. 

Program  slice  is  computed  using  the  transitive  closure  of  a  usage  to  definition  arc 
with  respect  to  a  variable. 

Newcomb  uses  the  idea  of  a  collision  former  to  hold  the  low-level  declarative  knowl¬ 
edge  in  his  system.  Each  Cobol  01  level  record  from  the  legacy  code  becomes  a  collision 
former.  The  collision  formers  do  not  describe  algorithms  or  designs,  as  would  a  plan.  They 
hold  the  structure  of  the  data  in  the  system.  The  procedural  knowledge  is  stored  in  control 
flow  and  data  flow  diagrams  derived  from  the  code. 
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The  collision  formers  are  used  to  do  alias  analysis,  i.e.  used  as  patterns  to  search 
through  the  other  record  structures  for  matches  Newcomb  calls  aliases.  Alias  analysis  is 
done  on  the  data  items  in  the  legacy  code  instead  of  on  the  routines  in  the  code  (as  in  plan 
recognition  systems).  Newcomb  creates  an  alias  map  that  maps  from  each  collision  former 
to  the  set  of  record  definitions  that  match  the  collision  former. 

Classes  in  the  object  model  are  formed  by  alias  analysis  and  collision  formation.  The 
classes  are  built  from  a  generalized  version  of  the  set  of  record  definitions,  and  the  instances 
of  the  classes  are  the  records  in  the  set.  The  fields  from  the.  01  records  are  assigned  to  the 
objects  as  attributes.  Currently,  Newcomb’s  object  modeling  process  does  not  construct 
class  hierarchies. 

Once  objects  are  found  through  alias  analysis,  Newcomb  takes  a  program  slice  focus¬ 
ing  on  one  object.  This  indicates  what  procedures  in  the  code  modify  or  use  the  object. 
Newcomb  presents  a  thorough  explanation  of  how  these  procedures  are  built  as  methods 
and  assigned  to  classes  of  objects. 

Overall,  Newcomb’s  system  is  important  because  of  the  work  in  extracting  function¬ 
ally  equivalent  objects.  Newcomb  claims  the  Object-Oriented  Model  (OOM)  extracted  is 
functionally  faithful  to  the  legacy  code,  but  does  not  provide  a  proof  of  this  claim. 

1. 3.2.2  Sneed’s  Work.  The  system  developed  by  Sneed  [67]  is  a  pre-cursor 
to  Newcomb’s  system  [47]  and  also  extracts  functionally  equivalent  objects  from  legacy 
code.  Sneed  uses  Cobol  record  structures  to  extract  objects.  Every  record  type  is  iden¬ 
tified  as  an  object  and  every  field  as  an  object  attribute.  The  methods  for  these  objects 
are  extracted  by  using  a  program  slicing  technique  Sneed  calls  phasing.  A  phase  is  an  ex¬ 
ecutable  sequence  of  statements  that  follows  the  data  flow  path  starting  at  an  input  from 
a  file  and  ending  at  an  output  to  a  file.  These  program  slices  are  attached  to  the  objects 
to  which  they  refer  and  become  methods  in  the  class  that  describes  these  objects. 

An  object-oriented  specification  is  built  for  each  extracted  object.  The  specification 
language  used  is  Z++,  an  object-oriented  version  of  the  Z  specification  language.  At  the 
end  of  the  reverse  engineering  process,  there  is  a  specification  for  each  method  and  the 
imperative  code  is  distributed  among  the  objects  in  the  target  system.  Sneed  claims  the 
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objects  extracted  are  functionally  equivalent  to  the  legacy  code,  and  uses  dynamic  profiling 
to  validate  this  claim.  Dynamic  profiling  is  a  technique  that  inserts  statements  in  the  legacy 
code  to  print  out  the  values  of  variables  at  certain  points  in  the  code.  The  values  of  the 
variables  are  collected  during  execution  of  the  legacy  system.  The  values  of  variables  in 
the  re-engineered  system  are  also  collected  during  execution  of  the  re-engineered  system. 
The  systems  are  functionally  equivalent  if  the  values  for  each  of  the  variables  in  the  legacy 
system  are  equal  to  the  values  for  that  variable  in  the  re-engineered  system. 

The  system  from  Sneed  is  an  interesting  data-driven  system  because  of  the  program 
slicing  and  the  extraction  of  functionally  equivalent  objects.  The  use  of  dynamic  profiling 
requires  execution  of  both  the  legacy  system  and  the  extracted  object  system,  which  limits 
the  practicality  of  Sneed’s  proof  of  functional  equivalence.  Furthermore,  errors  in  the 
transformation  of  the  legacy  system  are  not  discovered  until  the  re-engineered  system  is 
executed. 


1.3.2.S  Nyary’s  Work.  The  system  described  by  Nyary  [68]  automatically 
extracts  object-oriented  design  documentation  from  legacy  code.  Nyary  claims  the  design 
extracted  is  functionally  equivalent  to  the  legacy  code,  but  does  not  prove  this  claim.  The 
first  step  in  Nyary’s  approach  is  to  identify  several  different  types  of  objects  including  user 
interface,  information,  file,  record,  view,  work,  and  link  objects.  Nyary  gives  heuristics  for 
finding  each  type  of  object.  The  seven  types  of  objects  are  identified  and  stored  with  the 
names  and  descriptions  of  their  attributes. 

The  system  extracts  operations  for  these  objects  by  using  data-flow  and  control-flow 
information.  The  connections  between  objects  are  identified  by  examining  the  parameters 
of  routines  in  the  legacy  code  and  identifying  any  foreign  variables  in  the  object  operations. 
Foreign  variables  are  variables  used  by  an  operation  that  are  not  included  in  the  object 
associated  with  the  operation.  Nyary  claims  the  extracted  operations  are  functionally 
equivalent  to  the  legacy  code.  The  sequence  of  these  operations  is  expressed  as  a  state 
driven  model  (as  defined  by  Shlaer  and  Mellor  [63]). 

Nyary  presents  another  example  of  a  system  that  claims  to  extract  functionally  equiv¬ 
alent  objects.  Nyary  does  not  provide  any  formal  proof  of  this  claim. 
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1.3.2. 4  Achee  and  Carver’s  Work.  The  methodology  developed  by  Achee 
and  Carver  [1]  uses  statistical  analysis  of  subroutine  parameters  to  extract  objects  from 
legacy  FORTRAN  systems.  The  frequency  with  which  pairs  of  parameters  are  used  in 
different  subroutines  is  used  to  construct  the  “strongest  cohesive  unit”  [1].  Objects  are 
extracted  by  grouping  these  data  items  together  (to  form  the  cohesive  unit)  and  then 
attaching  methods  to  these  objects. 

Achee  and  Carver  do  not  claim  to  extract  functionally  equivalent  objects  from  legacy 
code.  Their  methodology  is  interesting  because  it  uses  subroutine  parameters  to  extract 
objects  using  a  statistical  method  rather  than  the  methodology  presented  in  this  document. 
Their  analysis  focuses  more  on  how  parameters  are  used  in  a  single  subroutine  than  on  the 
parameters  passed  between  several  subroutines. 

1.3. 2. 5  Liu,  Lividas,  and  Johnson’s  Work.  Lividas  and  Johnson  [43]  present 
three  techniques  that  use  data-driven  methods  to  extract  objects  from  legacy  code.  The 
first  two  techniques  were  developed  by  Liu  [42];  Lividas  and  Johnson  introduce  a  third. 
Lividas  and  Johnson  express  all  three  methods  for  object  identification  using  formal  defi¬ 
nitions.  These  definitions  are  presented  below. 

Let  P  be  an  imperative  program,  F  the  set  of  all  routines  in  P,  T  the  set  of  all  types 

in  P,  and  D  the  set  of  all  data  items  in  P.  A  candidate  object  [43]  is  a  triple  =  {(p,  r,  5) 

where  ip  C  F,  t  C  T,  6  C  D,  and  M  indicates  the  method  used  for  object  identification. 

Global-based  Object  Identification  (GBOI)  defines  a  triple  Cg  =  (9?,  0,x)  where 
ip  C  F  and  x  is  a  global  variable  with  respect  to  (p. 

Type-based  Object  Identification  (TBOI)  defines  a  triple  Cf  =  (c^,  r,  0)  where 

ip  C  F  and  r  C  T.  Here, 

n 

^  ^ 
i=l 

where  Uj  represent  the  types  of  the  parameters  and  b  the  type  of  the  returned  variable 
(if  any). 

Receiver-based  Object  Identification  (RBOI)  defines  a  triple  =  {ip,  r,  0)  where 
ip  Q  F  and  t  C  T.  Here, 

n 

i=l 
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where  rj  represent  the  types  of  the  parameters  that  are  changed  in  <p. 

These  three  techniques  identify  candidate  objects  in  imperative  programs  based  on 
relationships  between  the  data  items. 

1.3. 2. 6  Other  Data-Driven  Systems.  Figure  4  shows  several  other  data- 
driven  systems.  These  systems  are  described  briefly  in  this  section.  The  system  proposed 
by  Hausler  [29]  is  a  hybrid  of  the  plan  recognition  systems  and  the  data-driven  systems. 
Hausler  uses  program  slicing  to  isolate  pieces  of  legacy  code  and  then  uses  pattern  match¬ 
ing  to  recognize  plans  in  the  program  slices.  This  is  interesting  because  the  knowledge 
extracted  by  data-driven  means  is  being  used  to  limit  the  amount  of  code  considered  when 
matching  the  plans  to  the  code.  The  systems  from  Ferrante  [20]  and  from  Wilde  [77] 
capture  dependencies  in  legacy  code.  Horwitz  [30]  and  Weiser  [76]  present  data-driven 
methods  for  program  slicing.  These  four  contributions  provide  building  blocks  for  data- 
driven  reverse  engineering  tools.  The  knowledge  being  represented  is  at  the  language  level. 
The  systems  presented  by  Choi  [14]  and  by  Hutchens  [31]  use  data-driven  methods  to 
analyze  system  structure  of  legacy  code.  Choi  presents  a  method  for  extracting  various 
module  interconnection  diagrams  based  on  various  criteria.  The  system  built  by  Harris  [27] 
uses  program  slicing  and  recognition  rules  to  recognize  architectural  aspects  of  legacy  code. 
The  recognizers  used  are  similar  to  plans  because  they  structure  the  knowledge  being  rec¬ 
ognized,  but  the  recognizers  do  not  require  an  exact  match  in  the  legacy  code.  Program 
slicing  is  used  to  limit  the  amount  of  code  considered  when  matching  recognizers  to  code. 

The  system  proposed  by  Gall  [21]  uses  data  flow  diagrams  and  structure  charts  to 
cluster  procedures  and  data  together  into  objects.  Semantic  knowledge  is  added  to  the 
objects  found  by  comparing  them  to  an  independently  developed  object-oriented  model  of 
the  underlying  system.  The  OBAD  system  built  by  Yeh  [79]  (a  sub-system  of  the  Harris 
system  [27])  extracts  Abstract  Data  Types  (ADTs)  from  legacy  code.  This  system  first 
builds  a  graph  where  the  procedures  and  the  data  structure  types  are  the  nodes  and  the 
references  from  the  procedures  to  the  internal  fields  of  the  structures  are  the  edges.  The 
ADTs  are  extracted  from  the  connected  components  of  this  graph.  This  contribution  is 
included  under  the  objects  rubric  because  of  the  similarity  between  ADTs  and  objects  [11]. 


16 


The  system  developed  by  Ong  [50]  extracts  objects  from  FORTRAN  code.  The 
system  uses  information  from  the  COMMON  block  of  the  FORTRAN  code  to  organize 
data  and  procedures  into  objects.  The  work  presented  by  Jacobson  [33]  describes  an 
incremental  approach  for  re-engineering  legacy  code  to  the  object  paradigm.  An  interface 
is  built  from  the  new  object-oriented  part  of  the  system  to  the  part  of  the  system  not  being 
re-engineered. 

1.3.3  Informal  Information  Systems.  The  final  group  of  contributions  extract 
knowledge  from  the  informal  information  found  in  legacy  systems.  This  information  in¬ 
cludes  any  available  user’s  manuals,  programmer’s  manuals,  or  testing  manuals.  The  infor¬ 
mal  information  also  includes  the  comments  in  the  legacy  code  associated  with  the  piece  of 
code  being  analyzed.  The  DESIRE  system  from  Biggerstaff  [4-6]  uses  informal  information 
to  extract  domain  level  knowledge,  as  indicated  in  Figure  4.  DESIRE  uses  the  informal 
information  to  aid  program  understanding.  The  work  done  by  Lutsky  [45]  uses  informal 
information  in  legacy  system  documentation  to  generate  test  cases  for  legacy  systems.  The 
I-DOC  work  by  Johnson  [34]  automatically  answers  user’s  questions  about  a  legacy  system 
from  a  hyper-media  database  of  knowledge.  I-DOC  automates  the  informal  information 
associated  with  a  software  system. 

1.4  Summary 

The  data-driven  systems  presented  in  this  chapter  use  approaches  for  reverse  engi¬ 
neering  that  are  more  promising  than  the  approaches  used  by  plan  recognition  systems. 
Newcomb’s  system  [47],  for  example,  has  been  demonstrated  on  legacy  systems  as  large 
as  168,000  lines  of  Cobol  code.  The  data-driven  systems  are  more  scalable  because  they 
either  limit  the  amount  of  code  being  matched  against  plans  or  they  don’t  use  plans  at  all. 

Several  approaches  were  presented  that  extract  objects  from  legacy  code.  Some  of 
these  systems  claim  to  extract  functionally  equivalent  objects,  but  there  are  no  proofs 
of  these  claims.  Sneed  [67]  validates  his  claim  using  dynamic  profiling,  but  this  is  not 
practical  because  it  requires  the  extracted  object-oriented  design  to  be  implemented.  Any 
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error  introduced  in  the  transformation  would  not  be  uncovered  until  the  entire  design  was 
implemented. 

The  research  presented  in  this  document  is  similar  to  the  work  done  by  Newcomb  [47], 
Sneed  [67],  and  Nyary  [68],  as  indicated  in  Figure  4.  This  research  uses  data-driven  methods 
to  extract  an  object-oriented  design  that  includes  functionally  equivalent  objects. 

1.5  Summary  of  Contributions 

Given  the  overview  of  re-engineering  and  the  related  work  that  has  been  done  in  this 
area,  the  research  presented  in  this  document  makes  the  contributions  shown  below.  Each 
of  these  contributions  is  discussed  in  subsequent  chapters  and  a  more  detailed  summary  of 
the  contributions  is  provided  in  Chapter  IX. 

1.  An  object  identification  methodology  that  extracts  functionally  equivalent  objects 
from  legacy  imperative  code. 

2.  A  taxonomy  of  imperative  subprograms. 

3.  Formal  transformations  that  define  the  object  identification  methodology. 

4.  A  proof  of  functional  equivalence  between  the  legacy  imperative  code  and  the  ex¬ 
tracted  object-oriented  code. 

5.  A  canonical  form  for  representing  legacy  imperative  code. 

6.  A  surface  syntax  for  the  imperative  canonical  form. 

7.  A  canonical  form  for  representing  object-oriented  designs  and  code. 

8.  A  surface  syntax  for  the  object-oriented  canonical  form. 

9.  Definitions  of  the  formal  semantics  for  an  imperative  function  call. 

10.  Definitions  of  the  formal  semantics  for  an  object-oriented  message. 

1.6  Overview  of  Chapters 

Chapter  II  defines  in  detail  the  problem  of  re-engineering  imperative  systems  to  the 
object-oriented  paradigm.  Chapter  III  presents  the  generic  model  of  imperative  program¬ 
ming  languages  and  Chapter  IV  presents  the  generic  model  of  object-oriented  languages. 
Chapter  V  presents  the  taxonomy  of  imperative  subprograms,  the  methodology  for  extract¬ 
ing  objects  from  subprograms,  and  explains  how  program  slicing  [76]  is  used  to  simplify 
the  methodology.  Chapter  VI  presents  transformations  that  formalize  the  methodology. 


18 


Chapter  VII  presents  a  proof  that  the  extracted  design  is  functionally  equivalent  to  the 
legacy  system.  Chapter  VIII  presents  a  feasibility  demonstration  using  a  prototype  im¬ 
plementation  of  the  methodology.  Chapter  IX  describes  the  contributions  this  research 
makes  to  the  field  of  re-engineering.  Chapter  X  discusses  future  research  and  presents  the 
conclusions. 
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11.  Problem  Statement 


2.1  Introduction 

This  chapter  presents  a  summary  of  the  overall  re-engineering  methodology  developed 
by  this  research.  Each  part  of  the  methodology  is  explained  briefly  here  and  the  more 
significant  parts  are  explained  in  greater  detail  in  the  following  chapters. 

2.2  The  Re-Engineering  Methodology 

The  goal  of  this  research  is  to  develop  a  methodology  for  re-engineering  legacy  sys¬ 
tems  into  functionally  equivalent  object-oriented  designs.  Figure  5  shows  the  overall  view 
of  this  methodology.  In  the  figure,  the  large  rectangles  are  groupings  of  processes  and 
products  within  certain  paradigms.  The  large  box  on  the  left  shows  the  re-engineering 
processes  and  products  within  the  imperative  paradigm.  The  large  box  on  the  right  repre¬ 
sents  the  forward  engineering  processes  and  products  within  the  object-oriented  paradigm. 
The  large  box  in  the  middle  represents  versions  of  processes  and  products  in  the  object- 
oriented  paradigm  that  can  be  manipulated  automatically  with  a  computer.  The  “rounded- 
rectangles”  inside  the  large  boxes  represent  products  within  a  paradigm.  The  arrows  be¬ 
tween  rounded-rectangles  represent  processes  for  converting  one  product  to  another.  Each 
of  the  rounded-rectangles  is  discussed  in  the  sections  below.  The  dashed  rectangle  shows 
the  scope  of  this  research. 

2.2.1  Legacy  Code.  The  input  to  any  re-engineering  methodology  is  the  collection 
of  programming  language  code  to  be  transformed.  As  explained  in  Chapter  I,  this  code  is 
termed  legacy  code.  An  assumption  of  this  research  is  that  the  legacy  code  is  available  in 
some  format,  the  least  desirable  of  which  is  a  program  listing.  The  prototype  developed  to 
implement  this  research  further  assumes  the  legacy  code  can  be  accessed  by  a  computer. 

2.2.2  Canonical  Form.  The  first  step  in  the  re-engineering  methodology  is  to 
transform  the  legacy  code  into  a  canonical  form.  A  canonical  form  allows  code  that  does 
the  same  to  look  the  same.  A  canonical  form  is  language  independent,  programming 
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IF(ITYP.EQ.l)  THEN 
ALT  =  -5. 7 IDO 

ELSEIF(ITYP.EQ.2)  THEN 
ALT  =  -1.57D0 
ELSEIFCITYP.EQ.S)  THEN 
ALT  =  -9.46D0 
END  IF 


Figure  6  FORTRAN  elseif  structure 

construct  independent,  and  control  flow  construct  independent.  Each  of  these  aspects  is 
explained  in  the  following  sections. 

2.2.2. 1  Language  Independent.  A  canonical  form  is  language  independent, 
i.e.,  the  representation  is  not  tied  to  any  one  specific  programming  language.  This  allows 
the  re-engineering  methodology  to  operate  at  a  higher  level  of  abstraction,  encompass  more 
diverse  legacy  code,  and  be  built  independent  of  the  nuances  used  in  the  legacy  code. 

2. 2. 2. 2  Programming  Construct  Independent.  A  canonical  form  allows 
different  programming  language  constructs  to  be  recognized  as  the  same  entity.  Certain 
constructs  can  have  a  different  surface  syntax  but  provide  the  same  control  flow.  These 
constructs  are  easily  identified  because  they  have  equivalent  control  flow  graphs.  Wills  [60] 
refers  to  this  as  the  syntactic  variation  problem  as  discussed  in  Section  1.3. 1.1.  For  example. 
Figure  6  shows  the  FORTRAN  elseif  construct.  Not  all  programming  languages  have 
this  control  construct,  so  the  elseif  is  converted  to  embedded  if-then-else  statements 
in  the  canonical  form.  Embedded  if-then-else  statements  provide  the  same  control  flow 
as  the  elseif  statement,  thus  providing  the  canonical  form. 

2. 2. 2. 3  Simulated  Control  Flow  Constructs.  Another  use  of  the  canonical 
form  is  to  recognize  control  flow  constructs  not  implemented  in  the  legacy  code  program¬ 
ming  language.  For  example,  there  is  no  while  loop  in  FORTRAN,  but  it  can  be  simulated 
with  the  proper  combination  of  an  if-then  statement  and  a  goto  statement.  This  is  re¬ 
ferred  to  as  the  implementation  variation  problem  by  Wills  [60]. 
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150  IF(C2.GT.1.0D0)  THEN 
Cl  =  l.ODO  -  E**2 
C2  =  C1/C2GAM 
GO  TO  150 
END  IF 


Figure  7  Simulated  while  control  flow 

Figure  7  shows  FORTRAN  if-then  and  goto  statements  that  simulate  a  while  loop. 
By  recognizing  these  simulated  control  flow  structures  in  the  legacy  code,  they  can  be 
represented  in  the  canonical  form  as  the  control  flow  entity  they  emulate.  For  example, 
the  if-then  and  goto  structure  from  Figure  7  are  transformed  into  an  equivalent  while 
structure  in  the  canonical  form. 

2. 2.2. 4  Generic  Imperative  Model.  The  Generic  Imperative  Model  (GIM) 
has  been  developed  as  the  canonical  form  for  the  re-engineering  methodology,  as  shown  in 
Figure  5.  The  GIM  includes  fundamental  aspects  of  imperative  programming  languages 
such  as  FORTRAN,  C,  Pascal,  Cobol,  and  Ada  83.  Chapter  III  presents  the  GIM  in  detail. 

2.2.3  Program  Slices.  Once  the  legacy  code  is  converted  to  the  canonical  form, 
a  process  of  program  slicing  is  used  to  split  the  imperative  legacy  code  into  program  slices 
based  on  functionality  of  the  routines.  A  program  slice  [76]  is  the  collection  of  imperative 
programming  statements  extracted  from  a  legacy  program  that  are  required  to  produce  a 
single  value.  Program  slicing  over  entire  legacy  systems  has  been  used  in  such  applications 
as  software  maintenance  and  debugging  [22]  to  isolate  sections  of  code.  The  approach 
taken  in  this  research  is  to  use  program  slicing  on  a  single  legacy  subprogram,  as  discussed 
in  more  detail  in  Chapter  V. 

The  rationale  for  using  program  slicing  in  the  re-engineering  methodology  is  to  split 
the  legacy  code  into  separate  imperative  subprograms  that  resemble  object-oriented  meth¬ 
ods.  In  his  Object  Modeling  Technique,  Rumbaugh  [62]  defines  a  specific  type  of  object- 
oriented  method  called  queries.  A  query  of  an  object  returns  a  specific  value  from  the 
object.  By  using  program  slicing,  an  imperative  subprogram  that  returns  multiple  val- 


23 


ues  can  be  split  into  multiple  subprograms  that  each  return  a  single  value.  These  new 
subprograms  now  resemble  query  methods  and  can  be  built  into  an  object  class. 


2.2.4  Parameter-Based  Object  Identification  (PBOI).  This  section  describes  the 
arrow  shown  in  Figure  5  labeled  PBOI.  The  goal  of  this  step  is  to  organize  the  data 
and  associated  program  slices  into  objects  and  classes  that  comprise  the  extracted  object- 
oriented  design.  Chapter  V  describes  the  Parameter- Based  Object  Identification  (PBOI) 
methodology  developed  by  this  research  that  extracts  objects  based  on  the  data  items  being 
passed  throughout  the  legacy  system.  As  each  object  is  extracted,  a  class  is  built  in  the 
object-oriented  design  that  defines  the  attributes  and  operations  of  the  object.  As  a  final 
step  in  this  methodology,  duplicate  object  instances  are  eliminated  and  overlapping  classes 
are  merged.  This  is  explained  in  detail  in  Chapter  V.  In  order  to  scope  this  research, 
generalization  and  specialization  hierarchies  are  not  identified  for  the  extracted  classes. 
Each  class  is  built  as  a  sub-class  of  an  overall  super-class  resulting  in  a  flat  hierarchy  of 
classes. 

2.2.5  Generic  Object-Oriented  Design  Model.  The  Generic  Object-Oriented  De¬ 
sign  Model  (GOM)  is  a  canonical  form  that  models  any  object-oriented  design.  The  GOM 
has  been  developed  as  part  of  this  research  and  is  used  to  represent  the  extracted  design. 
The  design  is  built  by  creating  entities  from  the  GOM  such  as  objects,  classes,  messages, 
and  methods.  The  GOM  also  defines  a  design  entity  that  is  a  collection  of  the  extracted 
classes.  Chapter  IV  defines  the  GOM  in  detail. 

2.2.6  Generic  Object-Oriented  Program  Model.  The  Generic  Object-Oriented 
Program  Model  (GOM-P)  is  a  canonical  form  that  models  any  object-oriented  program. 
The  program  differs  from  the  design  in  that  the  object-oriented  methods  include  object- 
oriented  programming  statements.  This  research  assumes  the  statements  of  each  method 
are  from  the  imperative  programming  language  paradigm.  Part  of  the  re-engineering  pro¬ 
cess  is  to  transform  GIM  statements  to  GOM-P  statements.  The  GOM-P  models  languages 
such  as  C-f- h,  Java,  and  Ada  95.  Chapter  IV  defines  the  statements  that  are  modeled  in 
the  GOM-P. 
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2.2.1  Requirements  Specification.  Figure  5  shows  a  dashed  arrow  from  the  pro¬ 
gram  slices  to  the  requirements  specifications.  Although  this  specific  process  is  outside  the 
scope  of  this  research,  it  will  be  addressed  briefly.  It  may  be  possible  to  extract  specifi¬ 
cations  from  the  partitions  that  describe  the  functionality  of  the  imperative  code.  These 
requirements  specifications  might  be  used  to  create  an  equivalent  Object-Oriented  Analy¬ 
sis  (OOA).  Being  able  to  recover  accurate  specifications  of  the  legacy  code  would  clearly 
allow  a  more  extensive  and  robust  analysis  of  the  legacy  system.  However,  recovering 
specifications  from  code  is  considered  a  hard  problem  [44]  and  is  left  as  future  research. 

2.2.8  Generic  Object-Oriented  Analysis  Model.  The  Generic  Object-Oriented 
Analysis  Model  (GOM-A)  is  a  canonical  form  that  models  any  object-oriented  analysis.  Ac¬ 
cording  to  Rumbaugh  [62],  Object-Oriented  Analysis  (OOA)  differs  from  Object-Oriented 
Design  (OOD)  in  that  the  OOA  object  model  includes  associations  between  objects  and 
that  the  functional  and  dynamic  models  are  separate  in  OOA.  In  OOD,  the  dynamic  and 
functional  models  are  incorporated  into  the  object  model.  For  these  reasons,  the  GOM-A 
includes  entities  for  the  object,  dynamic,  and  functional  models.  It  also  includes  entities 
for  the  associations  between  objects.  It  is  hypothetically  possible  to  build  a  GOM-A  cov¬ 
ering  any  object-oriented  analysis.  The  GOM-A  is  not  included  as  part  of  this  research. 
DeLoach  [15]  has  done  work  in  this  area  and  developed  a  generic  model  of  the  Rumbaugh 
Object  Modeling  Technique  (OMT)  [62]. 

It  is  possible  to  convert  a  requirements  specification  recovered  from  the  imperative 
legacy  code  to  an  object-oriented  analysis  as  indicated  in  Figure  5,  but  this  research  does 
not  include  such  processing.  The  arrow  in  Figure  5  from  the  GOM  to  the  GOM-A  shows 
a  hypothetical  abstraction  process.  This  is  left  as  future  research. 

2.2.9  Object-Oriented  Program.  Once  the  OOD  has  been  built  by  the  re¬ 
engineering  methodology,  it  is  possible  to  convert  it  to  an  object-oriented  program.  This 
program  can  be  implemented  using  any  object-oriented  language  such  as  C-b- i-  [71]  or  Ada 
95  [3].  This  research  has  done  only  rudimentary  prototyping  of  this  step,  as  explained  in 
Chapter  VIII. 
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2.2.10  Object-Oriented  Products  and  Processes.  The  rounded-rectangles  in  Fig¬ 
ure  5  labeled  OOA,  OOD,  and  OOP  represent  the  products  of  Object-Oriented  Anal¬ 
ysis,  Object-Oriented  Design,  and  Object-Oriented  Programming,  respectively.  There 
are  currently  several  methodologies  for  analysis,  design,  and  programming  in  the  object 
paradigm  [9,10,62].  These  rounded-rectangles  are  included  in  the  figure  to  imply  a  correla¬ 
tion  between  the  object-oriented  design  produced  by  the  re-engineering  methodology  and 
an  object-oriented  design  produced  through  forward  object-oriented  analysis  and  design. 

2.2.11  Maintaining  Functional  Equivalence.  After  the  object  extraction  method¬ 
ology  has  been  used  on  an  imperative  legacy  system,  the  question  remains  about  the  utility 
of  the  transformation.  How  can  one  judge  that  the  object-oriented  design  produced  from 
the  methodology  is  of  any  value?  This  question  can  be  interpreted  in  at  least  two  different 
ways.  First,  the  question  could  be  asking  about  the  quality  of  the  design  and  whether  the 
recovered  design  is  a  good  object-oriented  design.  Second,  the  question  could  be  asking 
about  the  value  of  the  design  in  general  and  whether  representing  the  legacy  system  in  the 
object-oriented  paradigm  adds  value. 

The  former  view  requires  a  metric  to  determine  the  quality  of  an  object-oriented 
design.  This  is  an  open  research  issue  in  the  area  of  object-oriented  analysis  and  design, 
i.e.  there  is  currently  no  metric  that  accurately  judges  the  quality  of  an  object-oriented 
design.  There  is  only  an  informal  attempt  in  this  research  to  answer  the  question  from 
this  view. 

Instead,  the  value  of  the  object-oriented  design  recovered  is  judged  from  the  latter 
perspective.  If  it  can  be  shown  that  the  object-oriented  design  recovered  from  the  impera¬ 
tive  legacy  code  returns  the  same  output  as  the  legacy  system  given  the  same  input,  then 
the  design  is  quite  valuable.  Such  an  object-oriented  design  can  replace  an  aging  legacy 
system  and  provide  the  same  functionality  as  the  original  system  while  allowing  the  main¬ 
tenance  of  the  system  to  be  done  in  the  object-oriented  paradigm.  Chapter  VII  provides 
a  proof  that  the  design  extracted  using  this  methodology  is  functionally  equivalent  to  the 
legacy  code. 
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2.3  Summary 

This  chapter  has  presented  a  summary  of  the  re-engineering  methodology  defined 
in  this  research.  The  methodology  transforms  imperative  legacy  code  into  the  GIM,  uses 
program  slicing  on  the  subprograms,  extracts  objects  from  the  data  items  in  the  legacy 
system,  and  represents  the  extracted  design  using  the  GOM  and  GOM-P.  The  rationale  for 
each  of  these  steps  has  been  discussed  briefly  and  more  detailed  explanations  are  provided 
in  the  following  chapters.  Several  other  entities,  such  as  the  requirements  specifications 
and  the  GOM-A,  were  presented  and  left  for  future  research. 
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III.  The  Generic  Imperative  Model 

This  chapter  defines  the  Generic  Imperative  Model  (GIM)  developed  to  model  the  vari¬ 
ables,  expressions,  assignment  statements,  and  control  flow  typically  built  into  imperative 
programming  languages.  The  imperative  paradigm  is  discussed  first,  followed  by  detailed 
descriptions  of  how  these  traits  of  imperative  programming  languages  are  modeled  using 
Abstract  Syntax  Trees  (ASTs).  Rumbaugh’s  notation  [62]  for  classes  and  objects  is  used 
to  present  the  objects  and  classes  that  define  these  ASTs.  Formal  semantics  are  defined 
for  each  GIM  entity  using  the  weakest  precondition  notation  [18,19,24,25]. 


3.1  The  Imperative  Paradigm 

According  to  Dershem  [16],  there  are  currently  four  different  programming  language 
paradigms:  imperative,  logic,  functional,  and  object-oriented.  Tennent  [72]  and  Ghezzi 
and  Jazayeri  [23]  describe  the  imperative  programming  language  paradigm  as  a  style  of 
programming  based  on  the  following  concepts. 

Variables  Variables  hold  state  information  during  execution  of  the  program. 

Data  Types  Data  types  define  the  acceptable  values  for  a  variable  and  the  operations 
that  can  be  done  on  the  variable. 

Expressions  Expressions  are  combinations  of  variables  and  operators  used  to  express 
temporary  intermediate  values. 

Assignment  Statements  Assignment  statements  change  state  by  assigning  new 
values  to  variables  via  expression  evaluation. 

Input/Output  Input  and  output  statements  read  and  write  to  the  standard  in¬ 
put/output  devices  and  to  files. 

Sequential  Control  In  sequential  control  flow,  a  sequence  of  statements  executes 
one  after  another. 

Selective  Control  In  selective  control  flow,  a  choice  is  made,  based  on  the  result  of 
a  boolean  expression,  between  executing  one  sequence  of  statements  versus  another. 

Iterative  Control  In  iterative  control  flow,  a  sequence  of  statements  is  executed 
repeatedly  while  a  boolean  expression  is  true. 

Procedural  Abstraction  A  procedural  abstraction  collects  a  sequence  of  state¬ 
ments  that  are  executed  when  the  abstraction  is  referenced  by  name.  A  procedural 
abstraction  can  be  passed  parameters  and  may  return  values. 
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Main  Program  In  systems  of  imperative  subprograms,  there  is  always  one  subpro¬ 
gram  that  is  given  the  flow  of  control  as  the  system  begins  execution.  This  special 
subprogram  is  termed  the  main  program. 

Imperative  programming  languages  include  FORTRAN,  C,  Pascal,  Ada,  Cobol,  and 
others.  In  fact,  any  language  where  the  majority  of  the  language  implements  the  concepts 
presented  above  is  considered  an  imperative  programming  language.  These  are  the  concepts 
that  distinguish  the  imperative  paradigm  from  the  other  programming  language  paradigms. 

These  imperative  programming  language  constructs  are  modeled  in  the  GIM  by  build¬ 
ing  ASTs  that  store  knowledge  about  the  constructs.  For  a  specific  programming  language 
such  as  Ada  83,  it  is  possible  that  a  construct  in  the  language  is  not  part  of  the  impera¬ 
tive  paradigm.  For  example,  the  accept  and  entry  statements  implement  communication 
between  tasks  in  Ada  83.  These  statements  are  not  modeled  in  the  GIM  because  they  fall 
outside  the  definition  of  the  imperative  paradigm  presented  in  this  chapter.  Overall,  this 
means  certain  imperative  languages  can  not  be  completely  modeled  by  the  GIM.  The  Fea¬ 
sibility  Demonstration  Chapter  (Chapter  VIII)  discusses  a  method  for  determining  which 
parts  of  a  specific  language  can  be  modeled  by  the  GIM. 

The  organization  of  this  chapter  emphasizes  the  importance  of  assignment  and  control 
flow  in  the  imperative  paradigm  as  opposed  to  the  issues  of  data  storage  and  expressions. 
Unfortunately,  one  cannot  talk  about  assignment  without  variables  and  expressions.  The 
reader  is  referred  to  Section  3.14  and  Section  3.20  for  the  explanations  of  how  variables 
and  expressions,  respectively,  are  modeled  in  the  GIM. 

For  each  programming  language  construct  modeled  in  the  GIM,  formal  semantics 
are  provided  using  the  state  model  [19]  of  programs.  Preconditions  and  postconditions 
are  used  to  define  the  semantics  for  each  GIM  representation  of  an  imperative  construct. 
Specifically,  given  a  postcondition  R  that  is  guaranteed  to  be  true  after  a  statement  S  is 
executed,  the  weakest  precondition,  wp{S,  R),  defines  the  weakest  set  of  preconditions  that 
must  hold  in  order  for  the  execution  of  S  to  establish  R  [19].  This  research  relies  heavily 
on  the  previous  work  done  by  Djikstra  [18],  Gries  [25],  and  Dromey  [19]  to  define  formal 
semantics  for  imperative  programming  language  constructs. 
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3.2  The  GIM  Domain  Model 


This  section  presents  a  brief  overview  of  the  ASTs  that  are  included  in  the  GIM 
domain  model.  Figure  8  shows  a  partial  representation  of  the  GIM  domain  model.  The 
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Figure  8  GIM  Domain  Model 

overall  superclass  of  the  domain  is  the  imperative-domain  AST.  The  imperative-design 
class  models  collections  of  imperative  subprograms  as  defined  in  Section  3.8.  The  abstract 
class  imperative-statement  is  the  superclass  for  all  imperative  programming  statements 
modeled  in  the  GIM.  The  imperative-data-construct  class  is  the  superclass  of  imper¬ 
ative  expressions,  data  types,  and  variables  modeled  in  the  GIM.  Each  of  the  lower-level 
classes  in  the  domain  model  are  described  in  the  rest  of  this  chapter. 

3.3  Imperative  Assignment 

An  imperative  assignment  statement  takes  the  general  form  x  :=  e,  where  x  is  a 
variable  and  -e  is  an  expression  of  the  same  type.  When  this  statement  is  executed,  the 
expression  e  is  evaluated  and  the  result  is  assigned  to  x  [19].  Assignment  statements 
in  the  GIM  are  modeled  using  the  imperative-assignment  class.  Figure  9  shows  the 

imperative-assignment 

imp-assign-lhs :  imperative-variable 
imp-assign-rhs :  imperative-data-construct 

Figure  9  Imperative  Assignment  Class 

class  description  for  the  AST  that  models  imperative-assignment  in  the  GIM  (using 
Rumbaugh’s  notation  [62]).  The  imp-assign-lhs  attribute  models  the  variable  being 
assigned  a  value.  The  imp-assign-rhs  attribute  models  the  expression  to  be  evaluated  and 
assigned  to  the  variable.  When  variables  appear  on  the  right  hand  side  of  an  assignment. 
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they  are  considered  expressions.  The  GIM  is  able  to  model  both  variables  and  expressions 
on  the  right  hand  side  of  the  assignment  statement. 

As  an  example,  consider  the  following  C  assignment  statement. 

mfpgrc  =  0; 

This  assignment  statement  is  modeled  in  the  GIM  by  creating  an  instance  of  the  class 
imperative-assignment,  which  is  shown  in  Figure  9.  Figure  10  shows  the  object  instance 


Figure  10  Imperative  Assignment  Object 


that  models  this  C  assignment  statement  in  the  GIM.  The  variable  mfpgrc  is  modeled  as 
a  variable  in  the  GIM  (see  Section  3.14)  and  is  stored  in  the  imp-assign-lhs  attribute. 
The  value  0  is  modeled  as  a  literal  expression  (see  Section  3.20)  and  is  stored  in  the 
imp-assign-rhs  attribute  of  the  AST. 

The  semantics  for  the  GIM  assignment  statement  are  defined  formally  using  the 
weakest  precondition  notation.  Let  i?®  denote  the  postcondition  R,  with  all  free  occurrences 
of  X  simultaneously  replaced  by  e  [19].  The  semantics  for  the  general  form  of  imperative 
assignment,  x  :=  e,  are  defined  using  the  weakest  precondition  notation  as  shown  below. 

Definition  III.l.  wp{x  :=  e,  R)  =  i?® 

In  the  GIM,  the  imp-assign-lhs  models  x  and  the  imp-assign-rhs  models  e.  By 
relating  the  general  form  of  assignment  to  the  specific  representation  of  assignment  in  the 
GIM,  the  formal  semantics  for  assignment  in  the  GIM  are  now  defined. 

3-4  Imperative  Sequential  Control 

The  default  method  of  program  control  in  the  imperative  paradigm  is  sequential  con¬ 
trol  flow  where  a  sequence  of  statements  is  executed  one  statement  after  another.  Program 
statements  that  are  executed  sequentially  in  an  imperative  programming  language  are 
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modeled  in  the  GIM  by  storing  the  statements  in  a  sequence.  The  order  of  the  statements 
in  the  sequence  corresponds  to  the  order  of  the  statements  from  the  imperative  program. 

For  example,  in  the  collection  of  statements  shown  below,  <Statement  1>  is  executed 
followed  by  <Statement  2>  followed  by  <Statement  3>. 

<Statement  1> 

< Statement  2> 

<Statement  3> 

This  collection  of  statements  is  modeled  in  the  GIM  using  the  following  sequence. 
[<Statement  1>,  <Statement  2>,  <Statement  3>] 

The  semantics  for  sequential  control  in  the  GIM  are  based  on  the  semantics  of  the 
composition  command  [25]  and  are  defined  using  weakest  precondition  notation.  Let  51 
and  52  be  imperative  statements  and  [51, 52]  represent  the  sequential  composition  of  the 
two  statements. 

Definition  III. 2.  i(;p([51, 52],  R)  =  wp{Sl,  wp{S2,R)) 

Definition  III.2  leads  to  the  claim  that  the  GIM  representation  of  sequential  control 
flow  is  associative.  Let  51,  52,  and  53  be  imperative  statements. 

Theorem  III.l.  r(;p([5l,  [52, 53]],  R)  =  wp{[[Sl,S2],S3],  R) 


Proof. 

n;p([51,[52,53]],  R) 


t(;p(51,'«;p([52, 53],  R)) 
wp{Sl,wp{S2,wp{S3,  R))) 

tup([51,52],wp(53,  R))  (by  function  composition) 
n;p([[51,52],53],  R) 


□ 

Since  the  weakest  precondition  for  the  sequences  [51,  [52, 53]]  and  [[51,  52],  53]  are  equal, 
the  sequence  [51, 52,  53]  is  often  used  in  this  document  to  represent  these  sequences.  In 
addition,  singleton  sequences  and  empty  sequences  are  used  when  convenient. 
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3.5  Imperative  Selective  Control 

In  the  imperative  paradigm,  control  flow  consisting  of  a  selection  between  two  or 
more  statements  is  called  selective  control  flow.  The  selection  between  statements  51  and 
52  is  based  on  a  boolean  expression  B.  In  general,  selective  control  flow  takes  the  following 
form. 

if  B  then 

51 
else 

52 

To  be  more  specific,  51  and  52  above  may  consist  of  sequentially  composed  state¬ 
ments,  so  they  are  modeled  in  the  GIM  as  sequences  of  statements.  51  must  include  at 
least  one  statement  to  execute,  but  52  can  be  an  empty  sequence.  Selective  control  flow  is 
typified  in  imperative  programming  languages  by  the  if-then-else  statement.  Selective 
control  flow  where  52  is  empty  is  typified  in  the  imperative  paradigm  by  the  if-then 
statement. 

Selective  control  flow  is  modeled  in  the  GIM  by  using  the  imperative-selection 
class.  Figure  11  shows  the  class  description  for  the  imperative-selection  class.  The 

imperative-selection 

imperative-exp :  imperative-data-constmct 
imperative-then-part :  seq(imperative-program-constmct) 
imperative-else-part :  seq(imperative-program-constmct) 

Figure  11  Imperative  Selection  Class 

imperative-exp  attribute  models  the  boolean  expression  that  controls  the  selection.  The 
imperative-then-part  models  the  sequence  of  imperative  statements  that  are  executed  if 
the  boolean  expression  is  true.  The  imperative-else-part  attribute  models  the  sequence 
of  imperative  statements  that  are  executed  when  the  boolean  expression  is  false. 

For  example,  the  following  FORTRAN  if-then-else  statement  shows  a  choice  be¬ 
tween  executing  the  statement  LEXIST(I)  =  1  or  the  statement  LERROR  =  .TRUE.. 
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IF  (MFPGRC  .EQ.  0)  THEN 
LEXIST(I)  =  1 
ELSE 

LERROR  =  .TRUE. 

END  IF 

The  choice  is  made  based  on  the  value  of  the  boolean  expression  (MFPGRC  .EQ.  0). 
This  FORTRAN  if-then-else  statement  is  represented  in  the  GIM  as  shown  in  Figure  12. 


Figure  12  Imperative-Selection  Object 


The  imperative-exp  attribute  holds  the  <imperative-equal>  object  which  models 
the  expression  (MFPGRC  .EQ.  0).  The  imperative-then-part  attribute  holds  the  single- 
ton  sequence  containing  the  assignment  statement  from  the  then  part.  The  imperative- 
else-part  holds  the  singleton  sequence  containing  the  assignment  statement  from  the 
else  part. 

The  semantics  for  the  imperative-selection  statement  are  defined  using  weakest 
precondition  notation.  Let  B  represent  an  imperative  boolean  expression  and  let  SI  and 
S2  represent  sequences  of  imperative  statements.  The  general  form  of  selective  control 
fiow  presented  at  the  beginning  of  this  section  as  represented  in  the  GIM  is  given  by  the 
following  form. 

if  B  then  SI  else  S2 

The  sequence  SI  is  executed  if  B  is  true  and  the  sequence  S2  is  executed  if  B  is  false.  The 
semantics  of  this  GIM  form  of  selective  control  flow  are  defined  below. 

Definition  III.3.  wp{if  B  then  SI  else  S2,R)  =  {B  ^  wp{Sl,  R))  A{-^B  wp{S2,R)) 
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To  relate  these  formal  semantics  to  the  GIM,  note  that  B  is  modeled  using  the 
imperative-exp  attribute.  The  sequence  of  statements  51  is  modeled  by  the  imperative- 
then-part  attribute  and  the  sequence  52  is  modeled  by  the  imperative-else-part  at¬ 
tribute.  The  formal  semantics  for  selective  control  flow  as  modeled  in  the  GIM  are  now 
defined. 

The  formal  semantics  for  selective  control  flow  in  the  GIM  when  the  sequence  52 
is  empty  deserve  special  attention.  If  52  is  empty,  then  no  change  in  state  occurs  if  the 
boolean  expression  B  evaluates  to  false.  Let  skip  represent  a  statement  that  has  no  effect 
on  the  state  of  a  program. 

Definition  III.4.  iop(skip,  R)  —  R 

Selective  control  flow  in  the  GIM  when  52  is  empty  takes  the  following  form. 

if  B  then  51  else  skip 

The  formal  semantics  for  this  form  of  selective  control  in  the  GIM  is  defined  below. 
Definition  III.5.  wp{i£  B  then  51  else  skip,  R)  =  {B  wp{Sl,  R))  A  {-iB  R) 

3.6  Imperative  Iterative  Control 

The  imperative  paradigm  also  includes  a  control  mechanism  for  repeating  a  sequence 
of  statements  known  as  iterative  control  flow.  With  iterative  control  flow,  the  sequence 
of  statements  is  repeated  while  some  boolean  expression  is  true.  Let  B  represent  the 
boolean  expression  that  controls  the  iteration  and  51  represent  the  sequence  of  imperative 
statements  that  are  repeated.  The  general  form  of  iteration  in  the  imperative  paradigm  is 
defined  as 


while  B 
51 

Execution  of  the  sequence  51  continues  while  the  boolean  B  is  true. 
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Iteration  in  the  GIM  is  modeled  using  ASTs  built  from  the  imperative-iteration 
class.  Figure  13  shows  the  class  description  for  the  imperative-iteration  class.  The 

imperative-iteration 

iter-exp :  imperative-expression 

iter-body :  seq(imperative-program-constmct) 

Figure  13  Imperative-Iteration  Class 

iter-exp  attribute  models  the  boolean  expression  B  and  the  iter-body  attribute  models 
the  sequence  of  statements  51. 

For  example,  the  following  while  statement  from  Pascal  provides  an  example  of 
imperative  iteration. 

WHILE  Destination  >  Distance2  DO 
BEGIN 

Time  :=  Time  +  Interval; 

Distance2  :=  Distance2  +  Increment 
END 

This  WHILE  statement  is  modeled  using  the  imperative-iteration  object  shown  in 
Figure  14.  Other  imperative  programming  languages  include  statements  that  implement 


Figure  14  Imperative-Iteration  Object 


imperative  iteration,  for  example,  the  while  statement  in  C  and  the  loop  statement  in  Ada. 
These  statements  and  statements  in  other  programming  languages  provide  several  options 
for  implementing  imperative  iteration.  The  GIM  imperative-iteration  class  provides 
one  canonical  form  to  represent  these  looping  mechanisms.  Chapter  VIII  demonstrates  the 
conversion  of  the  FORTRAN  DO  loops,  FOR  loops,  and  loops  formed  through  the  structured 
use  of  the  GOTO  statement. 
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The  formal  semantics  of  iteration  in  the  GIM  are  defined  using  a  weakest  precon¬ 
dition  notation  based  on  the  guarded  loop  mechanism.  Given  a  precondition  P  and  a 
postcondition  R,  let  Hk{R)  represent  the  set  of  all  states  in  which 

while  B  do  Si 

will  establish  R  in  at  most  k  iterations  [19] . 

The  formal  semantics  for  iterative  control  fiow  in  the  GIM  are  defined  below. 

Definition  111.6.  wp{  while  B  do  SI,  R)  =  {3k  :  0  <  k  A  Hk{R)) 

To  tie  this  general  definition  to  the  specific  model  of  iterative  control  flow  in  the  GIM, 
recall  that  B  is  modeled  by  the  iter-exp  attribute  and  SI  is  modeled  by  the  iter-body 
attribute  of  the  imperative-iteration  class. 

Admittedly,  the  task  still  remains  to  define  Hk{R).  There  is  no  attempt  in  my 
research  to  define  loop  invariants  [19]  for  iteration  in  the  GIM.  What  is  provided  is  a 
general  definition  of  the  formal  semantics  for  iterative  control  flow. 

3.7  Imperative  Subprograms 

The  imperative  paradigm  allows  a  programmer  to  group  a  sequence  of  statements 
together  into  a  suitable  abstraction  unit  that  may  be  referenced  by  name.  This  mechanism 
is  known  as  the  subprogram  [23],  which  gives  a  name  to  a  sequence  of  statements.  A 
subprogram  call  invokes  the  abstraction  unit,  i.e.  forces  control  to  transfer  to  the  called 
unit,  which  upon  completion  returns  control  to  the  calling  point  [23]. 

Parameter  passing  conventions  allow  explicit  communication  between  a  subprogram 
and  a  call  to  the  subprogram  [23].  A  formal  parameter  appears  in  the  definition  of  a 
subprogram,  and  an  actual  parameter  appears  in  the  call  of  a  subprogram.  Note  that 
the  names  of  the  identifiers  used  as  actual  parameters  need  not  match  the  names  of  the 
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identifiers  of  the  formal  parameters  of  a  subprogram.  In  fact,  an  actual  parameter  need 
not  be  an  identifier  at  all  ,  but  can  be  an  expression  as  well^. 

The  following  definitions  are  needed  to  define  subprograms  more  fully. 

Definition  III.7.  A  data  item  has  a  definition  [2]  in  an  imperative  subprogram  when  the 
subprogram  includes  an  assignment  statement  or  an  input  statement  that  assigns  a  value 
to  the  data  item. 

Definition  III. 8.  A  subprogram  parameter  is  an  output  parameter  if  the  subprogram  in¬ 
cludes  a  definition  of  the  parameter.  A  parameter  is  also  an  output  parameter  if  the 
subprogram  invokes  another  subprogram  and  the  parameter  is  an  output  parameter  of  the 
called  subprogram. 

Definition  III. 9.  A  data  item  has  a  use  [2]  in  an  imperative  subprogram  when  any  of 
part  of  a  statement  in  the  subprogram  references  the  data  item  and  obtains  its  value. 

Definition  III. 10.  A  subprogram  parameter  is  an  input  parameter  if  a  use  of  the  param¬ 
eter  occurs  before  a  definition  of  the  parameter. 

Specific  exemplars  of  the  subprogram  in  the  GIM  include  procedures  and  functions. 
A  procedure  in  the  GIM  is  a  subprogram  that  does  not  explicitly  return  a  value  at  the 
end  of  its  processing.  Instead,  all  values  returned  from  procedures  are  returned  via  output 
parameters.  For  this  research,  the  following  restriction  applies  to  procedures  in  the  GIM. 

Restriction  III.l.  A  formal  parameter  of  a  procedure  must  not  be  both  an  input  and  an 
output  parameter. 

Appendix  D  provides  a  process  for  converting  procedures  with  a  parameter  that  is  both  an 
input  and  output  parameter  into  a  procedure  that  has  no  such  parameters.  A  function  in 
the  GIM  is  a  subprogram  abstraction  that  does  return  a  value  at  the  end  of  its  processing. 
For  this  research,  the  following  restriction  applies  to  functions  in  the  GIM. 

Restriction  III. 2.  All  functions  in  the  GIM  return  a  single  value  at  the  end  of  their 
execution  and  have  no  output  parameters. 

^This  aspect  of  parameter  passing  will  be  restricted  by  the  re-engineering  methodology,  as  described  in 
Section  3.11. 
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This  research  provides  no  process  for  converting  a  function  with  output  parameters  into  a 
function  with  no  output  parameters. 

3.8  Imperative  Designs 

In  order  to  model  the  collection  of  subprograms  as  a  whole,  the  subprograms  are 
stored  in  an  AST  built  from  the  GIM  class  imperative-design.  Figure  15  shows  the  class 

imperative-design 

imperative-programs :  seq(imperative-subprogram) 
imperative-files :  seq(imperative-file) 

Figure  15  GIM  Imperative  Design  Class 

description  of  the  imperative-design  class.  The  imperative -programs  attribute  holds 
the  collection  of  subprograms  that  comprise  the  design.  The  imperative-files  attribute 
holds  the  collection  of  input/output  files  being  modeled  for  this  design.  See  Section  3.21 
and  Section  3.22  for  discussions  of  how  input  and  output  statements  and  files  are  modeled 
in  the  GIM. 

3. 9  Imperative  Procedures 

Many  imperative  languages  include  a  construct  for  declaring  procedures.  In  FOR¬ 
TRAN,  the  SUBROUTINE  statement  is  used  to  define  the  name,  formal  parameters,  and 
statements  of  a  procedure. 

For  example,  the  FORTRAN  code  shown  in  Figure  16  defines  the  procedure  VADD. 
The  sequence  of  statements  included  in  the  body  of  this  procedure  will  be  executed  anytime 
the  VADD  procedure  is  called.  A  call  to  this  procedure  must  include  actual  parameters 
that  match  the  types  of  lOP,  Rl,  R2,  and  R3.  Other  examples  of  programming  language 
constructs  that  implement  procedures  are  the  procedure  constructs  in  Pascal  and  Ada. 

The  declaration  of  a  procedure  is  modeled  in  the  GIM  using  ASTs  built  from  the 
imperative-procedure  class.  Figure  17  shows  the  class  description  for  the  imperative- 
procedure  class.  The  imp-proc-identif  ier  attribute  is  used  to  model  the  name  of  the 
procedure.  The  imp-proc-f  ormals  attribute  models  the  sequence  of  formal  parameters 
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SUBROUTINE  VADD(I0P,R1,R2,R3) 

INCLUDE  'bdincl.f 
C 

C  THIS  ROUTINE  PERFORMS  VECTOR  ADDITION  FOR  THREE  DIMENSIONAL 
C  VECTORS 
C 

DIMENSION  R1(3),R2(3),R3(3) 

F  =  FLOAT(IOP) 

R3(l)  =  Rl(l)  +  F=«R2(1) 

R3(2)  =  Rl(2)  +  F*R2(2) 

R3(3)  =  Rl(3)  +  F*R2(3) 

RETURN 

END 


Figure  16  FORTRAN  Subroutine  VADD 

imperative-procedure 

imp-proc-identifier :  symbol 
imp-proc-formals :  seq(imperative-variable) 
imp-proc-statements :  seq(imperative-program-construct) 

Figure  17  GIM  Procedure  Class 

defined  for  the  procedure.  The  imp-proc-statements  attribute  holds  the  sequence  of 
statements  from  the  procedure.  Figure  18  shows  the  AST  object  that  models  the  FOR¬ 
TRAN  procedure  VADD  shown  in  Figure  16. 

The  declaration  of  a  subprogram  does  not  change  the  state  of  a  program.  It  is 
the  invocation  of  the  subprogram  that  may  affect  the  state.  For  this  reason,  the  formal 
semantics  for  subprogram  declarations  defined  in  this  section  serve  only  as  a  foundation 
for  the  definition  of  the  formal  semantics  of  subprogram  invocations. 

Let  S'!  represent  the  sequence  of  statements  declared  in  a  subprogram.  Let  P  rep¬ 
resent  the  precondition  of  51  and  let  R  represent  the  postcondition  of  51  such  that  the 
following  holds. 

{^} 

51 

{R} 


10 
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imp-proc-identifier 


(imperative-variable) 


(imperative-procedure)  ^ 

< 

> 

imp-proc-formals  | 

imp-proc-statements 


(imperative-variable) 

^  (imperative-assignment)^ 

(imperative-variable)  ^ 

(imperative-assignment)^ 

(imperative-variable)  ^ 

L  ■■■  J 

(imperative-variable)  ^ 

Figure  18  Modeling  a  Procedure 

For  a  subprogram  p,  let  5  be  a  vector  representing  the  input  parameters  of  p.  Let 
z  be  a  vector  representing  the  output  parameters  of  p.  Each  procedure  declaration  in  the 
GIM  takes  the  following  form. 

procedure  p{x,  z) 

{P} 

51 

{R} 


S.IO  Imperative  Functions 

Many  imperative  languages  also  provide  a  mechanism  for  declaring  functions.  For 
example,  the  FORTRAN  FUNCTION  statement  declares  a  function  that  returns  a  specific 
type  of  value  from  the  execution  of  the  statements  in  the  function. 

As  an  example,  consider  the  FORTRAN  function  declaration  found  in  Figure  19. 
This  function  returns  a  value  of  type  DOUBLE  PRECISION  after  the  statements  in  the  body 
of  the  function  are  executed.  A  call  to  this  function  must  include  actual  parameters  that 
match  the  data  type  of  BETA,  XLAMDA,  and  DIAM. 

Functions  in  the  imperative  paradigm  are  modeled  in  the  GIM  using  the  imperative- 
frmction  class.  Figure  20  shows  the  class  description  for  the  imperative-function  class. 
The  imp-func-identif  ier  attribute  holds  the  name  of  the  function  being  modeled.  The 
imp-fimc-formals  attribute  models  the  sequence  of  formal  parameters  defined  for  the 
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DOUBLE  PRECISION  function  PRDIV(BETA,XLAMDA,DIAM) 

INCLUDE  'bdincl.f 
C 

C  CALCULATES  THE  PROJECTOR  BEAM  DIVERGENCE  FOR  A  GIVEN  OPTICS 
C  SIZE  THIS  IS  BASED  ON  THE  RAYLEIGH  (AIRY  DISK)  CRITERION. 

C 

DATA  FAC/1.220D0/ 

QUAL  =  MAX(BETA,1.0D0) 

PDIAM  =  MAX(DIAM,0.1D0) 

WAVELN  =  XLAMDA*l.D-06 
PRDIV  =  QUAL*WAVELN*FAC/PDIAM 

RETURN 

END 


Figure  19  FORTRAN  Function  PRDIV 

imperative-function 

imp-fiinc-identifier :  symbol 
imp-func-formals :  seq(imperative-variable) 
imp-func-statements :  seq(imperative-program-construct) 
imp-function-retum-type :  imperative-data-type 

Figure  20  GIM  Function  Class 

function.  The  imp-func-statements  attribute  holds  the  sequence  of  statements  from  the 
function.  The  imp-frmction-return-type  attribute  models  the  data  type  of  the  value 
returned  from  the  function.  The  FORTRAN  function  PRDIV  shown  in  Figure  19  is  modeled 
in  the  GIM  using  the  imperative-function  object  shown  in  Figure  21. 

Because  of  Restriction  III. 2,  the  formal  semantics  of  a  function  declaration  are  defined 
more  restrictively  than  the  formal  semantics  of  a  procedure  declaration.  For  a  function  /, 
let  X  be  a  vector  representing  the  input  parameters  in  /.  Each  function  declaration  in  the 
GIM  takes  the  following  form. 

function  f{x) 

{P} 

SI 

{R} 


10 
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Figure  21  Modeling  a  Function 


In  order  to  define  the  semantics  for  the  value  that  is  returned  from  the  function  /, 
a  modified  representation  of  imperative  functions  is  used.  Let  y  represent  the  value  that 
is  returned  from  /.  Let  /'  be  a  procedure  that  takes  the  same  input  parameters  as  /,  and 
includes  y  as  the  single  output  parameter.  The  statements  in  f  are  the  statements  from 
/,  viz.  51.  The  procedure  f  takes  the  following  form. 

procedure  f'{x,  y) 

{P) 

51 

{R} 

This  modified  representation  of  imperative  functions  is  used  to  define  the  semantics 
of  a  function  invocation,  as  described  in  Section  3.12. 

3.11  Imperative  Procedure  Invocation 

If  an  imperative  language  provides  a  way  to  define  a  subprogram,  it  will  also  provide 
a  way  to  invoke  the  subprogram.  This  subprogram  call  mechanism  refers  to  the  called 
subprogram  by  name  and  passes  any  actual  parameters  required  by  the  subprogram.  This 
section  defines  one  of  the  specific  implementations  of  the  subprogram  call,  viz.  procedure 
calls. 

An  imperative  procedure  is  invoked  using  an  imperative  procedure  call,  which  is  a 
kind  of  statement  in  the  GIM.  The  call  to  a  procedure  is  modeled  in  the  GIM  using  ASTs 
built  from  the  imp-procedure-call  class.  Figure  22  shows  the  class  description  for  the 
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imp-procedure-call 

imp-proc-call-identifier :  symbol 
imp-proc-call-actuals  :  seq(imperative-variable) 

Figure  22  Imperative  Procedure  Call  Class 

imp-procedure-call  class.  The  imp-call-identifier  attribute  holds  the  name  of  the 
procedure  being  invoked.  The  imp-call-actuals  attribute  holds  the  actual  parameters 
used  in  the  procedure  call. 

For  example,  in  FORTRAN,  the  invocation  of  a  defined  SUBROUTINE  is  implemented 
using  the  CALL  statement.  The  FORTRAN  procedure  VADD  shown  in  Figure  16  is  invoked 
with  the  following  CALL  statement. 

CALL  VADDd,  Rl,  R2,  R3) 

This  procedure  call  invokes  the  procedure  VADD  and  passes  in  the  parameters  1,  Rl,  R2, 
and  R3. 


Figure  23  Imperative  Procedure  Invocation  Object 


Figure  23  shows  how  this  invocation  of  VADD  is  modeled  in  the  GIM  using  an  in¬ 
stance  of  the  imp-procedure-call  class.  Because  of  the  nature  of  the  object  extraction 
methodology,  actual  parameters  used  in  subprogram  calls  must  be  variables.  This  leads  to 
the  following  restriction  on  subprogram  calls. 

Restriction  III.3.  All  actual  parameters  in  subprograms  calls  must  be  variables. 
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For  this  reason,  actual  parameters  such  as  the  integer  1  in  Figure  23  are  replaced 
by  a  temporary  variable  and  an  assignment  statement  is  added  to  assign  this  variable  the 
value  of  the  parameter.  For  example,  the  original  GIM  call  to  VADD  is  shown  below. 

VADD  (  1,  Rl,  R2,  R3  ) 

The  updated  call  to  VADD  with  the  integer  actual  parameter  replaced  by  a  variable  is  shown 
below. 

TEMP-29  :=  1; 

VADD  (  TEMP-29,  Rl,  R2,  R3) ; 

The  formal  semantics  of  a  procedure  call  are  defined  as  follows.  Let  p  be  a  procedure 
and  let  51  be  the  sequence  of  statements  declared  in  p.  Let  a  be  a  vector  representing  the 
actual  parameters  that  correspond  to  input  parameters  in  p.  Let  c  be  a  vector  representing 
the  actual  parameters  that  correspond  to  output  parameters  in  p.  An  invocation  of  the 
procedure  p  takes  the  following  form.^ 

p(a,  c) 

To  invoke  p,  the  actual  parameters  are  copied  to  the  formal  parameters  and  control  fiow 
transfers  to  p.  Executing  the  procedure  call  is  equivalent  to  executing  the  following  se¬ 
quence. 


[x  :=  a,  51,  c  ;=  z] 

Using  weakest  precondition  notation,  the  semantics  for  a  procedure  call  are  defined  below. 
Definition  III.ll.  wp{p{a,c),R)  =  t(;p([x  :=  a,  51,  c  :=  z],  R) 

3.12  Imperative  Function  Invocation 

This  section  defines  the  other  specific  implementation  of  the  subprogram  call,  viz.  the 
function  call.  Most  imperative  languages  invoke  declared  functions  by  using  the  name  of 
the  function  and  passing  in  the  required  parameters.  A  function  call  is  a  kind  of  expression. 

^Here,  p  represents  both  the  procedure  entity  and  the  identifier  that  names  the  procedure. 
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Because  of  Restriction  111.3,  expressions  do  not  appear  in  procedure  calls  but  do  appear  in 
assignment,  selective,  and  iterative  statements.  This  implies  function  calls  do  not  appear 
in  procedure  calls  in  the  GIM,  but  can  appear  in  the  other  statements.  The  call  to  a 
function  is  modeled  in  the  GIM  using  the  imp-function-call  class.  Figure  24  shows 

imp-fiinction-call 

imp-fun-call-identifier ;  symbol 
imp-fun-call-actuals :  seq(imperative-variable) 

Figure  24  Imperative  Function  Call  Class 

the  class  description  for  the  imp-function-call  class.  The  imp-fun-call-identifier 
attribute  holds  the  name  of  the  procedure  being  invoked.  The  imp-fun-call-actuals 
attribute  holds  the  actual  parameters  used  in  the  function  call. 

An  important  difference  between  the  invocation  of  procedures  and  functions  in  the 
imperative  paradigm  is  that  procedure  calls  can  only  appear  as  whole  statements  and  not 
part  of  another  statement.  Function  calls  can  only  appear  as  part  of  an  expression  that  is 
part  of  another  statement  and  not  as  whole  statements  themselves. 

For  example,  the  FORTRAN  function  PRDIV  shown  in  Figure  19  is  invoked  as  part 
of  the  following  statement. 

SIGPR  =  PRDIV (BETA,  XLAMDA,  DIAM) 

This  function  call  invokes  the  function  PRDIV  passing  in  the  parameters  BETA,  XLAMDA,  and 
DIAM.  The  result  of  this  function  call  is  used  as  the  expression  assigned  to  the  variable 
SIGPR.  Figure  25  shows  how  the  invocation  of  PRDIV  is  modeled  in  the  GIM  using  an 


Figure  25  Imperative  Function  Invocation  Object 
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instance  of  the  imp-function-call  class. 


The  formal  semantics  for  function  calls  in  the  GIM  are  defined  as  follows.  Let  / 
be  a  function  and  let  51  be  the  sequence  of  statements  declared  in  /.  Let  a  be  a  vector 
representing  the  actual  parameters  that  correspond  to  the  input  parameters  in  /.  Since 
every  function  appears  as  part  of  an  expression  in  some  statement,  let  5  represent  the 
statement  in  which  /  appears.  Recall  the  modified  representation  of  a  function  presented 
in  Section  3.10  includes  one  output  parameter,  y,  which  represents  the  value  returned  from 
the  function  /.  Let  f  be  the  procedure  that  represents  /  with  the  input  parameters  from 
/  and  the  additional  parameter  y.  Let  b  represent  the  actual  parameter  that  corresponds 
to  y. 

Using  these  definitions,  an  invocation  of  the  function  /  takes  the  following  form. 

m 

An  invocation  of  the  procedure,  /',  takes  the  following  form. 

The  difference  between  the  invocations  of  /  and  f  is  that  the  invocation  of  /  is  part  of  5 
and  the  invocation  of  f  is  a  single  statement.  Invoking  /  is  equivalent  to  invoking  f  and 
then  substituting  6  in  5  for  any  invocations  of  /.  This  provides  a  formal  representation  of 
the  value  returned  from  /.  The  substitution  of  b  for  the  call  to  /  in  5  is  represented  by 
the  following  notation. 

In  this  way,  the  call  to  /  is  equivalent  to  the  following  sequence  of  statements. 
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As  defined  in  Section  3.11,  when  the  procedure  f  is  invoked,  the  actual  parameters  in 
a  are  copied  to  the  formal  parameters  in  x  and  control  flow  transfers  to  /'.  After  execution 
of  the  function,  the  value  of  y  is  copied  to  b.  Hence,  executing  the  call  to  /'  is  equivalent 
to  executing  the  following  sequence. 


[a:  a,Sl,b:=  y] 


Using  weakest  precondition  notation,  the  formal  semantics  of  a  call  to  function  /, 
where  the  statement  S  contains  /(a),  are  defined  below. 

Definition  III.12.  wp(S,  R)  =  wp{[x  :=  a,Sl,b  :=  y,  R) 

3.13  Recursion 

In  the  imperative  paradigm,  it  is  possible  for  a  subprogram  to  invoke  itself  in  a  process 
known  as  recursion.  Knuth  [37]  claims  that  any  recursive  algorithm  can  be  transformed 
into  an  iterative  algorithm.  For  this  reason,  the  GIM  does  not  model  recursion.  This  leads 
to  the  following  restriction. 

Restriction  III.4.  Subprograms  to  be  modeled  in  the  GIM  are  not  allowed  to  make  calls 
to  themselves. 

Even  more  restrictively,  the  call  tree  consisting  of  the  graph  of  subprogram  calls  made 
in  a  collection  of  imperative  subprograms  is  assumed  to  be  a  directed  acyclic  graph  or  DAG. 

Restriction  III.  5.  The  call  tree  of  a  collection  of  imperative  subprograms  must  be  a  di¬ 
rected  acyclic  graph. 

3.14  Imperative  Variables 

Each  variable  that  is  set  or  used  in  an  imperative  program  is  modeled  in  the  GIM 
AST  by  building  an  imperative -variable  object.  Figure  26  shows  the  class  description 
for  the  imperative-variable  object.  The  imp-data- sc  ope  attribute  models  the  name  of 
the  procedural  abstraction  in  which  this  variable  is  defined.  The  imp-data-identif ier 
attribute  models  the  name  of  the  imperative  variable.  The  imp-data-type  attribute  is  an 
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imperative-variable 

imp-data-scope :  symbol 
imp-data-identifier :  symbol 
imp-data-type :  imperative-data-type 
imp-data-indices :  seq(imperative-data-construct) 
imp-constant-value :  any-type 


Figure  26  Imperative- Variable  Class 


object  that  describes  the  data  type  of  the  imperative  variable.  The  imp-data-indices 
attribute  stores  the  GIM  representations  of  the  indices  for  this  variable,  if  any.  The 
imp-constant-value  attribute  stores  the  value  assigned  to  the  variable  if  the  variable 
is  a  constant. 


(imperative-variable) 

imp-data-scope  =  WC 
imp-data-identifier  =  mfpgrc 
imp-data-indices  =  [  ] 
^imp-constant-value  =  *undefined^ 

imp-data-type 


(imperative-integer) 
imp-type-size  =  4 


Figure  27  Imperative- Variable  Object 


For  example,  Figure  27  shows  how  the  C  integer  variable  mfpgrc,  defined  in  a  pro¬ 
cedure  WC,  is  represented  in  the  GIM.  Here,  the  variable  mfpgrc  is  modeled  by  building 
an  instance  of  the  imperative -variable  class  representing  an  integer  variable  with  no 
indices  and  no  constant  value.  The  imp-data-scope  attribute  is  set  to  the  symbol  WC 
since  this  is  the  name  of  the  procedure  in  which  this  variable  is  defined.  Scoping  issues  are 
discussed  in  more  detail  in  Section  3.16.  The  data  type  of  mfpgrc  is  modeled  using  the 
imperative-integer  object  in  the  GIM.  Certain  data  types  are  modeled  in  the  GIM  as 
discussed  in  Section  3.15. 


3.15  Imperative  Data  Types 

In  order  to  model  variables  in  the  GIM,  certain  data  types  are  also  modeled.  The 
data  types  being  modeled  are: 
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Integer  zero  and  positive  and  negative  whole  numbers 
Real  rationals  and  irrationals 
Boolean  true  and  false  logical  values 
Character  single  alpha  characters 
String  sequences  of  characters 

Array  homogeneous  collections  of  elements  accessed  with  an  index. 

Each  of  the  classes  representing  these  data  types  has  an  attribute  imp-type-size 
that  indicates  the  number  of  bytes  associated  with  the  data  type.  Some  imperative  lan¬ 
guages  allow  the  programmer  to  specify  the  size  of  the  data  type  at  the  declaration  of  a 
variable.  Other  languages  do  not  allow  this,  but  include  types  of  different  sizes  to  meet 
data  storage  requirements.  Programmer-defined  data  type  sizes  are  modeled  in  the  GIM 
by  storing  the  specified  size  in  the  imp-type-size  attribute.  For  languages  that  do  not 
allow  the  programmer  to  define  the  size  of  the  data  type,  the  size  of  the  built-in  type  must 
be  determined  and  stored  into  the  imp-type-size  attribute. 

For  example,  in  the  FORTRAN  programming  language,  the  programmer  is  allowed 
to  declare  the  size  of  the  data  type  when  declaring  variables.  The  MFPGRC  variable  from 
Section  3.14  can  be  declared  as  shown  below. 

INTEGER*4  MFPGRC 

The  integer  data  type  is  represented  using  the  imperative-integer  object.  Figure  28 

imperative-integer 
imp-type-size  =  integer 

Figure  28  Imperative-Data-Type  Class 

shows  the  class  description  for  imperative-integer.  The  imp-type-size  attribute  indi¬ 
cates  the  size  of  the  data  type.  The  four  byte  FORTRAN  integer  data  type  used  to  declare 
MFPGRC  in  the  example  above  is  represented  using  the  imperative-integer  object  shown 
in  Figure  29. 

In  the  C  programming  language,  the  programmer  must  use  intrinsic  data  types  to 
specify  the  size  of  data  storage  locations.  The  int  data  type  in  C  is  normally  the  natural 
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(imperative-integer) 
imp-type-size  =  4 


Figure  29  Four  Byte  Integer  Object 

size  for  a  particular  host  machine:  either  16  or  32  bits  [35],  The  short  or  long  qualifier 
can  be  applied  to  the  basic  C  types  to  change  the  number  of  bytes  used  for  the  variable. 
A  short  integer  is  often  2  bytes  and  a  long  integer  is  often  4  bytes  [35] .  In  order  to  model 
these  data  types  in  the  GIM,  the  size  of  the  intrinsic  data  types  and  qualifiers  must  be 
determined  for  a  specific  compiler  in  order  to  store  the  correct  value  for  the  imp-type-size 
attribute  of  the  imperative  data  type  objects. 

In  C,  the  MFPGRC  variable  can  be  declared  as  follows: 

short  MFPGRC; 

Here,  an  imperative -integer  object  with  the  imp-type-size  attribute  set  to  2  correctly 
models  the  data  type  of  the  MFPGRC  variable,  as  shown  in  Figure  30. 

r  (imperative-integer) 
imp-type-size  =  2 

Figure  30  Two  Byte  Integer  Object 


3.16  Imperative  Scoping  Issues 

In  the  imperative  paradigm,  the  “visibility”  a  variable  has  to  subprograms  is  known 
as  the  scope  [72]  of  the  variable.  A  subprogram  that  defines  a  variable  has  visibility  to  it, 
but  different  imperative  programming  languages  provide  different  rules  for  the  visibility  of 
the  variable  to  other  subprograms. 

Each  subprogram  in  the  GIM  has  a  local  scope  in  which  the  variables  declared  are 
not  visible  to  any  other  subprograms.  The  GIM  subprogram  that  declared  the  variable 
can  share  its  value  by  passing  the  variable  to  other  subprograms  as  a  parameter.  Passing  a 
local  variable  to  another  subprogram  as  an  actual  parameter  has  the  effect  of  making  the 
variable  visible  to  the  called  subprogram.  In  the  imperative  paradigm,  this  is  termed  pass 
by  reference  parameter  passing  [16].  All  parameters  in  the  GIM  are  passed  by  reference. 
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Variables  declared  in  the  main  program  are  considered  to  be  in  the  global  scope.  Some 
imperative  programming  languages  allow  subprograms  to  directly  access  variables  declared 
in  the  global  scope,  i.e.  without  passing  the  variable  to  the  subprogram  via  a  parameter. 
This  is  not  modeled  in  the  GIM  and  leads  to  the  following  restriction  on  variable  scoping 
in  the  GIM. 

Restriction  III.6.  All  variables  in  a  subprogram  are  either  declared  locally  or  are  formal 
parameters  of  the  subprogram. 

In  the  imperative  paradigm,  some  programming  languages  allow  subprograms  to  be 
declared  inside  another  subprogram.  This  leads  to  a  nesting  of  variable  scopes  where 
variables  in  the  “outer”  subprogram  are  visible  to  the  “inner”  subprogram.  Declaring  a 
subprogram  inside  another  subprogram  is  not  modeled  in  the  GIM  which  leads  to  the 
following  restriction  on  declaring  subprograms  in  the  GIM. 

Restriction  III.  7.  Subprograms  can  not  be  declared  inside  of  another  subprogram.  They 
are  all  declared  in  the  main  program’s  global  scope. 

3.17  Imperative  Homogeneous  Data  Structures 

In  the  imperative  paradigm,  collections  of  homogeneous  elements  can  be  built  using 
constructs  such  as  lists  and  arrays.  The  only  such  collection  modeled  in  the  GIM  is  the 
array.  An  array  is  an  indexable  collection  of  homogeneous  elements.  Variables  in  the  GIM 
can  be  of  the  data  type  array.  The  indices  used  to  access  an  array  element  are  modeled 
using  the  imp-indices  attribute  of  the  imperative -variable  class. 

For  example,  an  access  to  the  first  element  of  a  FORTRAN  array  R  used  in  a  subpro¬ 
gram  VADD  is  modeled  in  the  GIM  as  shown  in  Figure  31  The  imp-data-indices  attribute 
models  the  expression  or  variable  being  used  to  access  the  element  of  the  array.  In  the 
figure,  the  access  to  the  first  element  of  the  array  R  is  modeled  by  storing  the  literal  value 
1  as  the  index  into  the  array. 
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(imperative-variable) 
imp-data-scope  =  VADD 
imp-data-identifier  =  R 
imp-constant-value  =  *undefined* 


imp-data-type  j  imp-data-indices 


Figure  31  Imperative  Array  Access  Object 


3.18  Imperative  Heterogeneous  Data  Structures 

Some  programming  languages  in  the  imperative  paradigm,  allow  the  programmer  to 
build  collections  of  heterogeneous  data  items,  e.g.  records  in  Pascal  and  structs  in  C.  These 
heterogeneous  data  structures  are  not  modeled  in  the  GIM,  which  leads  to  the  following 
restriction. 

Restriction  III.8.  The  GIM  does  not  model  heterogeneous  data  structures. 

3.19  Imperative  Pointers 

Some  imperative  programming  languages  allow  the  programmer  to  store  the  address 
of  a  variable  and  then  access  the  variable  via  the  address.  This  mechanism  is  typically 
referred  to  as  using  pointers  to  variables.  Pointers  are  not  modeled  in  the  GIM,  which 
leads  to  the  following  restriction. 

Restriction  III.9.  The  GIM  does  not  model  pointers. 

3.20  Imperative  Expressions 

In  the  imperative  paradigm,  expressions  can  be  literal  values,  unary  or  binary  ex¬ 
pressions  with  operators,  function  calls,  or  even  variables.  This  section  describes  how 
expressions  are  modeled  in  the  GIM. 

Literal  values  in  the  GIM  are  modeled  by  the  imperative-literal-consteuit  class. 
Figure  32  shows  the  class  description  for  the  imperative-literal-constcint  class.  The 
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imperative-literal-constant 
imperative-literal-value :  any-type 

Figure  32  Modeling  Imperative  Literal  Constants 

imperative-literal-value  attribute  models  the  value  of  the  literal.  Figure  33  shows  all 

imperative-literal-boolean 

imperative-literal-integer 

imperative-literal-real 

imperative-literal-string 

Figure  33  List  of  Imperative  Literal  Constants 

the  literal  constants  currently  modeled  in  the  GIM.  Each  literal  shown  is  modeled  as  an 
AST  defined  as  a  subclass  of  the  imperative-literal-constant  class.  Literal  constants 
other  than  those  listed  in  Figure  33  are  not  modeled  in  the  GIM,  but  could  easily  be 
modeled  by  defining  a  new  subclass  under  the  imperative-literal-constant  class  that 
describes  the  new  literal  constant. 

Unary  expressions  in  the  GIM  are  modeled  using  the  imperative-imary-expression 
class.  Figure  34  shows  the  class  description  for  the  imperative-unary-expression  class. 

imperative-unary-expression 
imp-unary-operand :  imperative-expression 

Figure  34  Modeling  Imperative  Unary  Expressions 

The  imp-unary-operand  attribute  models  the  single  operand  of  the  unary  expression. 
Figure  35  shows  all  the  unary  expressions  currently  modeled  in  the  GIM.  Each  unary 
expression  shown  is  modeled  as  an  AST  defined  as  a  subclass  of  the  imperative-unary- 
expression  class.  As  with  literal  constants,  any  unary  expressions  other  than  those  listed 
in  Figure  35  are  not  modeled  in  the  GIM  but  can  be  by  building  a  new  subclass  that 
defines  the  new  unary  expression. 

Binary  expressions  in  the  GIM  are  modeled  by  the  imperative-binary-expression 
class.  Figure  36  shows  the  class  description  for  imperative-binary-expression  class.  Bi¬ 
nary  expressions  in  the  imperative  paradigm  either  have  two  operands  or  multiple  operands. 
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imperative-negate 

imperative-not 


Figure  35  List  of  Imperative  Unary  Expressions 

imperative-binary-expression 

imp-bin-exp-operand- 1 :  imperative-name 
imp-bin-exp-operand-2 ;  imperative-data-constmct 
imp-bin-exp-seq :  seq(imperative-expression) 


Figure  36  Modeling  Imperative  Binary  Expression 


For  this  reason,  the  imperative-binary-expression  class  has  three  attributes  for  mod¬ 
eling  the  operands  of  the  expression.  The  imp-bin-exp-operand- 1  and  imp-bin-exp- 
operand-2  attributes  hold  the  two  operands  if  the  binary  expression  has  only  two  operands. 
When  the  same  binary  expression  is  repeated  for  multiple  operands,  such  as  in  the  expres¬ 
sion  A  +  B  +  C,  the  multiple  operands  are  modeled  in  the  imp-bin-exp-seq  attribute. 
Certain  binary  expressions  can  be  repeated  in  this  way,  e.g.  addition  and  subtraction. 
Others  can  not  be  repeated  in  this  way,  e.g.  <,  <=,  and  >.  Figure  37  lists  all  the  binary  ex¬ 


imperative-division 

imperative-equal 

imperative-exponent 

imperative-greater-than-or-equal 

imperative-greater-than 

imperative-less-than-or-equal 

imperative-less-than 

imperative-not-equal 

imperative-subtraction 


imperative-addition 

imperative-and 

imperative-concat 

imperative-multiplication 

imperative-or 


(a)  Two  operand. 


(b)  Sequence. 


Figure  37  List  of  Binary  Expressions  Modeled  in  the  GIM 


pressions  that  are  modeled  in  the  GIM.  The  binary  expressions  that  can  not  be  repeated  are 
shown  in  Figure  37(a).  These  expressions  are  modeled  using  the  imp-bin-exp-operand- 1 
and  imp-bin-exp-operand-2  attributes.  The  binary  expressions  that  can  be  repeated 
are  shown  in  Figure  37(b).  These  expressions  are  modeled  using  the  imp-bin-exp-seq 
attribute. 
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As  with  literal  constants  and  unary  expressions,  any  binary  expressions  not  shown 
in  Figure  37  are  not  modeled  by  the  GIM.  This  new  binary  expression  could  be  modeled 
by  adding  a  subclass  to  the  imperative-binary-expression  class  that  defines  the  new 
binary  expression. 

3.21  Imperative  Input 

Programming  languages  in  the  imperative  paradigm  allow  the  programmer  to  interact 
with  the  user  via  input  and  output  statements.  These  statements,  if  directed  towards  a 
file,  allow  the  programmer  to  implement  persistent  storage  of  data.  This  section  describes 
how  input  statements  in  imperative  languages  are  modeled  in  the  GIM. 

In  order  to  receive  data  values  from  outside  an  imperative  program,  imperative  pro¬ 
gramming  languages  provide  the  programmer  with  an  input  statement.  This  statement 
can  be  used  to  communicate  with  the  user  or  used  to  input  data  from  a  file.  The  Cobol 
programming  language  actually  has  two  statements:  one  for  inputting  low-volume  data 
and  one  for  inputting  data  from  a  file.  For  example,  the  following  Cobol  ACCEPT  statement 
is  used  to  input  a  program  name  from  the  user  using  the  console  typewriter. 

ACCEPT  PROGRAM-NAME  FROM  CONSOLE. 

Input  statements  are  modeled  in  the  GIM  using  the  imperative-input  object. 
Figure  38  shows  the  class  description  for  this  object.  The  imp-in-logical-file  attribute 

imperative-input 

imp-in-logical-file :  imperative-data-construct 
imp-input-list :  seq(imperative-data-construct) 

Figure  38  Imperative  Input  Class 

is  used  to  model  from  where  the  input  is  coming.  When  the  input  comes  from  the  user, 
the  attribute  is  set  to  an  accepted  value  that  models  that  fact.  The  imp-input-list 
attribute  holds  the  sequence  of  data  items  being  input.  Figure  39  shows  how  the  Cobol 
ACCEPT  statement  is  modeled  in  the  GIM,  assuming  the  PROGRAM-NAME  variable  is  defined 
in  a  procedure  called  GET-INFO.  The  imp-in-logical-file  attribute,  in  this  example, 
has  been  arbitrarily  set  to  the  symbol  console  in  order  to  represent  input  from  the  user 
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(imperative-input) 
imp-in-logical-file  =  ’console 


imp-input-list 


(imperative-name) 
imp-scope  =  WC 

imp-identifier  =  PROGRAM-NAME 
\imp-indices  =  [  ] 


Figure  39  Imperative  Input  Object 


console.  As  long  as  this  attribute  is  set  consistently,  receiving  input  from  the  user  can  be 
modeled  in  this  way. 

In  imperative  languages,  when  the  programmer  wants  to  input  from  a  file,  the  file 
must  first  be  “opened”.  The  act  of  opening  a  file  establishes  the  link  between  the  physical 
file  on  disk  and  the  logical  file  in  the  program.  The  status  of  the  file,  e.g.  opened  for  input 
or  output,  and  the  access  mode  of  the  file,  e.g.  direct  or  sequential,  are  also  established 
when  the  file  is  opened.  This  information  about  the  file  is  modeled  in  the  GIM  using 
the  imperative-file  object.  Figure  40  shows  the  class  description  for  this  object.  The 

imperative-file 

imp-designator :  imperative-data-construct 
imp-file-name :  imperative-data-constract 
imp-access :  symbol 
imp-status :  symbol 

Figure  40  Imperative  File  Class 


imp-designator  attribute  holds  name  of  the  logical  file  as  referenced  in  the  program. 
The  imp-access  attribute  holds  the  access  type,  direct  or  sequential,  for  the  file.  The 
imp-status  attribute  holds  the  status  of  the  file,  opened  either  for  input  or  output.  In 
Cobol,  the  OPEN  statement  is  used  to  open  a  file.  The  following  Cobol  OPEN  statement 
opens  a  file  MASTER-FILE  for  input.  The  access  mode  is  assumed  to  be  sequential. 

OPEN  INPUT  MASTER-FILE 

Figure  41  shows  how  this  file  is  modeled  in  the  GIM.  The  name  of  the  file  being  opened  is 
used  as  the  file  designator. 
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(imperative-file) 
imp-designator  =  MASTER-FILE 
imp-status  =  INPUT 
imp-access  =  SEQUENTIAL 


Figure  41  Modeling  MASTER-FILE 


Once  files  are  opened,  input  statements  are  used  to  input  data  from  the  files.  In 
Cobol,  the  READ  statement  is  used  to  input  data  from  a  file.  For  example,  the  following 
READ  statement  reads  the  next  record  from  the  file  MASTER-FILE  and  stores  it  into  the 
variable  MASTER-WORK. 

READ  MASTER-FILE  INTO  MASTER-WORK 
AT  END  PERFORM  END-DATA-MASTER. 

Figure  42  shows  how  this  READ  statement  is  modeled  in  the  GIM.  The  imp-in-logical- 


imp-in-logical-file 

!  (imperative-name) 

imp-scope  =  GET-INFO 
imp-identifier  =  MASTER-FILE 


\^imp 


-indices  =  [  ] 


imp-input-list 


(imperative-name) 
imp-scope  =  GET-INFO 
imp-identifier  =  MASTER-WORK 
'^imp-indices  =  [  ] _ 


Figure  42  Modeling  the  COBOL  Read 


file  attribute,  in  this  example,  has  been  set  to  an  imperative  name  object  referring  to 
the  file  MASTER-FILE  in  order  to  indicate  the  input  is  coming  from  this  specific  file. 

The  semantics  of  the  GIM  input  statement  are  similar  to  the  semantics  of  the  GIM 
assignment  statement.  Both  statements  define  values  for  variables.  Abstractly,  an  input 
statement  in  the  GIM  is  equivalent  to  calling  a  subprogram  where  all  the  parameters  are 
output  from  the  subprogram. 

For  example,  let  1  represent  an  input  statement  and  let  d  represent  a  vector  holding 
the  variables  that  appear  in  1.  Let  x  represent  a  vector  of  variables  returned  from  the 
input  statement  after  the  values  are  read  from  the  indicated  file  (or  the  console).  Then, 


58 


execution  of  the  GIM  input  statement  is  equivalent  to  the  following  sequence: 


[/,  a  a;] 

The  formal  semantics  for  the  input  statement  I  are  defined  below. 

Definition  III.13.  wp{I{a),  R)  =  wp{[I{a),  a  :=  x],  R) 

3.22  Imperative  Output 

This  section  describes  how  output  statements  in  imperative  languages  are  modeled 
in  the  GIM.  In  order  to  communicate  the  values  of  variables  outside  a  program,  imper¬ 
ative  programming  languages  provide  the  programmer  with  an  output  statement.  This 
statement  is  used  to  communicate  with  the  user  or  store  values  in  data  files.  The  output 
statement  is  modeled  in  the  GIM  using  the  imperative-output  object.  Figure  43  shows 

imperative-output 

imp-out-logical-file :  imperative-data-construct 
imp-output-list :  seq(imperative-data-constmct) 

Figure  43  Imperative-Output  Class 

the  class  description  for  this  object.  The  imp-out-logical-file  attribute  is  used  to  store 
the  logical  link  to  a  file  opened  for  output.  The  imp-output-list  attribute  holds  the  list 
of  data  items  to  be  output.  The  data  items  are  modeled  using  imperative-output-item 
objects.  Figure  44  shows  the  class  description  for  the  imperative-output-item  object. 

imperative-output-item 

imp-out-item :  imperative-expression 
imp-format ;  imperative-format 

Figure  44  Imperative  Output  Item 

The  imp-out-item  attribute  holds  the  expression  to  be  output.  The  imp-format  attribute 
holds  formatting  information  for  the  item  to  be  output.  This  attribute  models  the  output 
formatting  implemented  in  some  imperative  languages,  e.g.  total  number  of  spaces  in  the 
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output  or  number  of  digits  to  output  after  the  decimal  point.  If  the  output  item  is  not 
being  formatted  in  any  way,  the  imp-format  attribute  is  empty. 

In  COBOL,  there  are  two  output  statements:  one  for  low-volume  output  and  the 
other  for  output  to  a  data  file.  The  DISPLAY  statement  is  used  in  COBOL  to  output  data 
to  the  user.  For  example,  the  following  COBOL  DISPLAY  statement  is  used  to  prompt  the 
user  for  the  program  name  outputting  to  the  console  screen. 

DISPLAY  ’ENTER  PROGRAM  NAME’ 

UPON  CONSOLE. 

Figure  45  shows  how  the  COBOL  DISPLAY  statement  is  modeled  in  the  GIM.  In  this 


Figure  45  Modeling  the  COBOL  Display 


example,  the  imp-out-logical-file  attribute  has  been  set  to  the  symbol  STD-OUT  to 
indicate  output  to  the  standard  output  port.  As  with  input,  as  long  as  the  standard 
I/O  ports  are  modeled  consistently,  output  to  the  user  can  be  modeled  in  this  way.  The 
imp-format  attribute  is  empty  indicating  this  output  is  not  formatted. 

In  COBOL,  the  WRITE  statement  is  used  when  the  programmer  wants  to  output  data 
values  to  a  file.  After  the  file  has  been  opened  for  output,  a  data  record  is  associated  with 
the  file  and  this  data  record  can  be  output  to  the  file.  While  this  mechanism  is  more  com¬ 
plicated  than  the  mechanism  in  COBOL  for  reading  from  a  file,  writing  to  a  file  can  still  be 
modeled  in  the  GIM  by  determining  with  which  file  a  record  is  associated  and  storing  this 
information  in  the  imperative-output  object.  For  example,  the  following  COBOL  pro¬ 
gram,  ADDRESS-LISTING,  declares  a  file  ADDRESS-LIST,  declares  a  record  OUTPUT-RECORD 
associated  with  the  file,  opens  the  file  for  output,  and  writes  a  record  to  the  file. 
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PROGRAM-ID. 

PROGRAM- ADDRESSES . 

FILE-CONTROL. 

SELECT  ADDRESS-LIST  ASSIGN  TO  UR-1403-S-0UTFILE. 
FILE  SECTION. 

FD  ADDRESS-LIST 
01  OUTPUT-RECORD. 

05  LAST-NAME  PICTURE  X(12) . 

PROCEDURE  DIVISION. 

MAIN-ROUTINE. 

OPEN  OUTPUT  ADDRESS-LIST 
ACCEPT  OUTPUT-RECORD  FROM  CONSOLE. 

WRITE  OUTPUT-RECORD. 


Figure  46  shows  how  the  COBOL  WRITE  statement  is  modeled  in  the  GIM.  In  this  example, 


imp-out-logical-fUe 


(imperative-output) 


(imperative-name) 
imp-scope  =  PROG-ADDRESS 
imp-identifier  =  ADDRESS-LIST 
(imp-indices  =  [  ] 


imp-output-list 


(imperative-name) 
imp-scope  =  PROG-ADDRESS 
imp-identifier  =  OUTPUT-RECORD 
V  imp-indices  =  [  ] 

^ 


Figure  46  Modeling  the  COBOL  Write 


the  connection  between  OUTPUT-RECORD  and  the  file  ADDRESS-LIST  is  used  to  determine 
the  value  of  the  imp-out-logical-file  attribute.  Even  though  the  logical  file  is  not 
explicitly  referenced  in  the  WRITE  statement,  the  indirect  reference  can  be  used  to  model 
output  to  the  file. 

The  semantics  of  the  GIM  output  statement  are  defined  using  the  weakest  precon¬ 
dition  notation.  Semantically,  the  output  statement  is  not  allowed  to  change  the  state  of 
the  program.  Let  O  represent  an  output  statement  in  the  GIM.  The  formal  semantics  of 
the  output  statement  are  defined  as 

Definition  III.14.  wp(0,  R)  =  R 
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This  means  the  GIM  output  statement  can  have  no  side-effects  that  would  change  the 
state.  In  this  way,  the  input  and  output  statements  provided  by  imperative  programming 
languages  are  modeled  in  the  GIM. 

The  following  sections  provide  formal  definitions  for  imperative  subprograms  and 
subprogram  calls.  These  definitions  are  used  throughout  the  rest  of  this  document  to  build 
formal  transformations. 

S.23  Formalizing  GIM  Statements  and  Expressions 

This  section  presents  formal  representation  for  GIM  statements  and  expressions. 
These  formal  representations  are  used  in  the  formal  transformations  presented  in  Chap¬ 
ter  VI.  Let  X  represent  a  GIM  variable  and  let  e  represent  a  GIM  expression.  A  GIM 
assignment  statement  is  represented  formally  by  the  following  tuple. 

<  X,  :=,  e  > 

This  tuple  indicates  that  x  is  the  variable  to  be  assigned  the  value  of  the  expression  e.  The 
:=  symbol  is  a  syntactic  token  that  distinguishes  this  tuple  as  an  assignment  statement. 

Let  e  represent  a  GIM  expression  and  let  5i  and  S2  represent  sequences  of  GIM 
statements.  A  GIM  selection  statement  is  represented  by  the  following  tuple. 

<  if,  e,  then,  5i,  else,  ^2  > 

This  tuple  indicates  that  the  sequence  of  statements  Si  will  be  executed  if  the  expression 
e  evaluates  to  true  otherwise  the  S2  sequence  will  be  executed.  The  if,  then,  and  else 
symbols  are  syntactic  tokens  used  to  identify  this  tuple. 

Similarly,  let  e  represent  a  GIM  expression  and  let  represent  a  sequence  of  GIM 
statements.  The  GIM  iteration  statement  is  represented  by  the  following  tuple. 

<  while,  e,  Sz  > 
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This  indicates  that  the  sequence  of  statements  S3  will  be  executed  while  the  expression  e 
is  true.  The  while  symbol  is  a  syntactic  token  used  to  identify  this  tuple. 

Let  E  represent  a  sequence  of  expressions.  The  GIM  input  and  output  statements 
are  represented  formally  by  the  following  tuples. 


<  input,  iport,  E  > 

<  output,  oport,jEJ  > 

These  tuples  indicate  the  expressions  in  the  sequence  E  are  either  input  from  the 
input  port  iport  or  output  to  the  output  port  oport. 

Expressions  in  the  GIM  are  represented  formally  by  the  following  tuples.  Let  ei  and 
62  be  GIM  expressions. 


<  Cl, +,62  > 

<  61,  and,  62  > 
<  61,  concat,62  > 
<61,  /,62  > 

<  ei,  =,  62  > 
<ei,  **,62  > 

<  ei,>=,62  > 

<  ei,>,e2  > 

<  ei,<=,62  > 

<  ei,<,e2  > 

<  ei,  *,62  > 

<  ei,<>,62  > 

<  61,  or,  62  > 

<  ei,  -,62  > 

<  -,ei  > 

<  not,  61  > 
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3.24  Formalizing  Imperative  Subprograms 

This  section  explains  how  subprograms  modeled  by  the  GIM  imperative-procedure 
and  imperative-fimction  ASTs  can  be  represented  more  mathematically. 

The  following  definitions  are  used  to  formally  define  subprograms. 

ids  -  A  symbol  storing  the  subprogram’s  name. 

Pin  -  The  sequence  of  input  parameters. 

Pout  -  The  sequence  of  output  parameters. 

Pj-ei  -  The  sequence  of  returned  values. 

Ploc  ~  The  sequence  of  local  variables. 

E  -  The  sequence  of  statements  from  the  subprogram. 

Thus,  a  subprogram  is  defined  by  the  following  tuple. 

<  idsf  Pin^  Pouti  Preti  Ploci  ^  ^ 

Several  of  the  attributes  of  imperative  subprograms  are  sequences  of  imperative  vari¬ 
ables,  viz.  Pin,  Pouti  Preti  and  Pioc-  In  order  to  manipulate  these  sequences  formally,  the 
four  special  sequence  operators,  0,  0,  C,  and  pos  are  defined  below. 

S'!  0  ^2  =  Si  concat  [a;  |  x  €  S2  A  x  ^  Si] 

Si  ©  S2  =  [x  I  X  G  Si  A  X  0  S2] 

Si  Q  S2  =  V  X  G  Si  X  G  S2 

pos(x,  E)  Let  the  pos  operation  indicate  the  ordinal  position  of  the  element  x  in  the  se¬ 
quence  E. 

For  example.  Figure  47  shows  the  imperative  subprogram  UPLREQ.  This  subprogram 
is  formally  defined  by  the  following  tuple. 
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DOUBLE  PRECISION  function  UPLREQ(ZCOS,XLAMDA,SIGTRB) 

INCLUDE  'bdincl.f 
C 

DATA  SIGT0/3.75D-06/ 

C 

TMPl  =  XLAMDA*ZCOS*ZCOS*ZCOS 
TMP2  =  TMP1++0.200 
C 

C  SIGUP  IS  THE  UPLINK  BEAM  DIVERGENCE  DUE  TO  TURBULENCE  FOR  10 

C  A  BEAM  WITH  NO  PHASE  CORRECTION. 

C 

SIGUP  =  SIGT0ITMP2 
C 

IF(SIGTRB.GT.O.O)  THEN 
UPLREQ  =  SIGUP/SIGTRB 
ELSE 

UPLREQ  =  lOOOOOO.ODO 

END  IF 

RETURN  20 

END 


Figure  47  FORTRAN  Function  UPLREQ 

<  U PLREQ,  Pin,  Pout,  Pret,  Ploc,  S  >  where 
Pin  =  [ZCOS,  XLAMDA,  SIGTRB]  and 
Pout  —  [  ]  and 
Pret  =  [UPLREQ]  and 
Ploc  =  [SIGTO,  TMPl,  TMP2,  SIGUP]  and 
S  =  statements  between  DATA  and  END 

The  input  parameters  of  UPLREQ  are  the  data  items  ZCOS,  XLAMDA,  and  SIGTRB. 
UPLREQ  has  no  output  parameters  and  the  data  item  returned  from  the  execution  of  the 
UPLREQ  function  is  represented  by  including  the  identifier  UPLREQ  in  the  Pj-et  sequence.  The 
local  variables  of  UPLREQ  are  the  data  items  SIGTO,  TMPl,  TMP2,  and  SIGUP.  The  sequence 
of  imperative  statements  between  the  BEGIN  and  the  END  of  UPLREQ  comprise  S. 
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3.25  Formalizing  Imperative  Subprogram  Calls 

This  section  provides  formal  definitions  of  the  GIM  imp-procedure-call  entity,  a 
kind  of  statement,  and  the  GIM  imperative-fimction-call  entity,  a  kind  of  expression. 

The  calling  relationship  between  any  two  subprograms  can  be  defined  formally  as 
follows.  Let  Si  be  the  calling  subprogram  and  let  S2  be  the  called  subprogram.  Let  idg^ 
be  a  symbol  that  holds  the  name  of  the  called  subprogram.  Let  Pforms^  ^  sequence  of 
variables  that  are  formal  parameters  of  the  calling  subprogram,  i.e.  {Pins^  ®  Pouts^)- 
^ocisj  be  a  sequence  of  variables  that  are  actual  parameters  in  the  calling  subprogram, 
where  Pacts^  E  {Pforms.^  ®  Plocs^)-  Thus,  a  call  to  the  subprogram  S2  by  subprogram  5i 
is  represented  by  the  following  tuple. 

In  the  imperative  paradigm,  the  number,  order,  and  type  of  parameters  in  Pacts^  must 
match  the  number,  order,  and  type  of  the  parameters  in  Pforms^  called  subprogram. 

This  link  between  an  actual  parameter  in  a  call  to  a  subprogram  and  the  formal 
parameter  in  the  called  subprogram  is  important  in  re-engineering.  Even  though  one 
subprogram  can  have  multiple  calls  to  another  subprogram  or  can  call  many  other  sub¬ 
programs,  a  static  mapping  between  actuals  and  formals  of  each  call  can  be  built.  For 
each  call  to  a  subprogram,  the  order  of  the  actual  parameters  determines  to  which  formal 
parameter  in  the  called  subprogram  the  actual  parameter  is  mapped. 

Definition  III.15.  The  p  map  links  an  actual  parameter  from  the  calling  program  to  a 
single  formal  parameter  in  the  called  subprogram. 

Let  /  be  a  call  from  subprogram  Si  to  subprogram  S2.  Let  pi  be  an  actual  parameter 
in  1.  Let  p2  be  a  formal  parameter  in  the  subprogram  82-  Let  pos{pi,  Pacti)  indicate  the  po¬ 
sition  the  parameter  pi  takes  in  the  sequence  of  actual  parameters  Pacti  •  Pos{p2,  Pfcn-rm) 
indicate  the  position  of  p2  in  the  sequence  of  formal  parameters  Pform2- 

The  p  relation  is  defined  formally  as  follows. 
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m(w)  =  P2  where 

/  ^  5  P %cti  ^  CLTtd 

S2  —  <  ^dg2i  Piny  Pouti  Preti  Ploci^  ^  fflTlci 

Pform  ~  Pin  ®  Pout  0,nd 

Pi  G  -Poet,  and 

P2  €  P/orm 

pos{pi,  Pacti)  ~  Pas{p2,  Pform) 


DOUBLE  PRECISION  function  PRDIV(BETA.XLAMDA,DIAM) 

INCLUDE  'bdincl.f 
C 

C  CALCULATES  THE  PROJECTOR  BEAM  DIVERGENCE  FOR  A  GIVEN  OPTICS 
C  SIZE  THIS  IS  BASED  ON  THE  RAYLEIGH  (AIRY  DISK)  CRITERION 
C 

DATA  FACI1.220D0I 

QUAL  =  MAX(BETA,1.0D0) 

PDIAM  =  MAX(DIAM,0,1D0) 

WAVELN  =  XLAMDA*l.D-06 

PRDIV  =  QUAL*WAVELN*FAC/PDIAM 

RETURN 

END 


Figure  48  FORTRAN  Function  PRDIV 

For  example,  Figure  48  shows  the  declaration  of  the  imperative  subprogram  PRDIV 
that  has  three  formal  parameters,  BETA,  XLAMDA,  and  DIAM. 

Figure  49  shows  the  partial  declaration  of  the  subprogram  RELAY  and  the  call  to  the 
subprogram  PRDIV.  In  this  example,  let 

I  =  <  PRDIV,  [B,  X,  DIAM]  > 

Thus,  the  actuals  in  I  and  the  formats  from  relay  are  defined  as  follows. 


Pacti  =  [B,  X,  DIAM]  and 

P/ormpRDiv  =  [beta,  XLAMDA,  DIAM] 


10 
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SUBROUTINE  RELAY(B,X,DIAM) 
INCLUDE  'bdincl.f 


C 

C  DESE  RESEARCH  AND  ENGINEERING,  INC.  (21  MAY  1985) 

C 

C 

C  FIRST  THE  PROJECTOR  DIVERGENCE 
C 

SIGPR  =  PRDIV(B,X,DIAM) 

SIGPSQ  =  SIGPR*SIGPR 
C 

RETURN 

END 


Figure  49  FORTRAN  Subroutine  RELAY 

Let  represent  a  /x  mapping  from  an  actual  parameter  to  a  formal  parameter. 
Hence,  the  following  mappings  are  included  in  the  fi  relation. 

RELAY::B  PRDIV::BETA 

RELAYuX  PRDIV::XLAMDA 

RELAY::DIAM  PRDIVuDIAM 

Note  that  the  identifiers  used  to  name  the  parameters  may  or  may  not  be  the  same. 
In  the  example,  the  scope  of  the  parameter  is  used  to  differentiate  between  actuals  and 
formals  using  the  same  identifier.  For  example,  the  PRDIV :  :  prefix  indicates  the  scope  of 
a  variable  is  PRDIV.  In  this  way,  the  DIAM  variable  from  PRDIV  is  distinguished  from  the 
DIAM  variable  in  RELAY. 

3.26  Formalizing  Imperative  Designs 

This  section  provides  a  formal  representation  for  imperative  designs.  Formal  trans¬ 
formations  that  add  subprograms  to  a  design  and  remove  subprograms  from  a  design  are 
also  provided. 

The  formal  definition  of  an  imperative  design  is  provided  below.  Let  S*  represent 
the  set  of  subprograms  included  in  the  design.  An  imperative  design,  SD,  is  represented 
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formally  by  the  following  tuple. 


SD  =  S* 

An  imperative  design  consists  of  the  set  of  imperative  subprograms  to  be  included  in  the 
design. 

Let  be  a  transformation  of  an  imperative  design  that  adds  a  new  subprogram  to 
an  existing  design  and  returns  a  new  imperative  design.  Let  SD  represent  an  imperative 
design  and  let  S  represent  the  subprogram  to  be  added  to  the  design.  The  transformation 
is  defined  below. 


T^{SD,S)  =  SD'  where 
SD'  =  SDLi{S} 

Let  T~  be  a  transformation  of  an  imperative  design  that  removes  a  subprogram 
from  an  existing  design  and  returns  a  new  imperative  design.  Let  SD  represent  an  im¬ 
perative  design  and  let  S  represent  the  subprogram  to  be  removed  from  the  design.  The 
transformation  is  defined  below. 


T-iSD,S)  =  SD'  where 
SD'  =  SD-{S} 


3.27  Summary 

This  chapter  has  defined  the  Generic  Imperative  Model  (GIM)  that  is  used  to  model 
assignment,  variables,  expressions,  and  control  flow  constructs  in  imperative  programming 
languages. 

Several  restrictions  have  been  placed  on  the  GIM.  Some  of  these  restrictions  are 
meant  to  canonicalize  the  representations  in  the  GIM.  Others  place  limits  on  which  imper¬ 
ative  entities  can  possibly  be  modeled  using  the  GIM.  Specifically,  Restriction  III.l  states 
that  a  parameter  of  a  procedure  can  not  be  both  an  input  and  an  output  parameter.  This 
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restriction  is  meant  to  simplify  the  way  parameters  are  modeled.  This  restriction  is  not 
unreasonable  since  any  procedures  that  do  not  meet  the  restriction  can  be  converted  using 
the  process  presented  in  Appendix  D.  Similarly,  Restriction  III.  2  does  not  allow  functions 
to  include  output  parameters  or  return  more  than  a  single  data  item.  It  is  hypothetically 
possible  to  convert  such  functions  into  procedures  and  then  represent  the  procedures  in 
the  GIM.  Restriction  III.3  requires  all  parameters  in  subprogram  calls  to  be  variables. 
Parameters  that  are  not  variables  are  easily  converted  to  a  temporary  variable,  so  this  is 
a  reasonable  restriction  of  the  GIM.  Restrictions  III.4  and  III.5  limit  subprogram  calls  to 
non-recursive  calls.  This  restriction  is  reasonable  because  Knuth  [37]  argues  any  recursive 
algorithm  can  be  represented  using  an  iterative  algorithm.  Restriction  III.6  does  not  allow 
global  variables  to  appear  in  subprograms.  This  means  subprograms  with  variables  other 
than  formal  parameters  or  local  variables  must  first  be  converted  into  the  proper  form.  It 
is  hypothetically  possible  to  convert  global  variables  into  formal  parameters  throughout 
the  call  tree  of  a  legacy  system,  so  this  restriction  is  not  unreasonable.  Restriction  III.7 
does  not  allow  one  subprogram  to  be  declared  inside  another  subprogram.  The  scoping 
issues  involved  in  this  nesting  of  subprograms  is  more  complicated  than  that  of  imper¬ 
ative  variables,  but  it  is  hypothetically  possible  to  convert  the  nested  subprograms  into 
subprograms  declared  at  the  global  level. 

None  of  the  restrictions  discussed  above  preclude  the  representation  of  imperative 
entities  in  the  GIM.  However,  Restriction  III.8  states  that  heterogeneous  data  types  are 
not  modeled  in  the  GIM.  Restriction  III.9  states  that  pointers  are  not  modeled  in  the 
GIM.  These  two  restrictions  limit  the  entities  that  can  be  modeled  by  the  GIM.  If  the 
legacy  system  includes  either  heterogeneous  data  types  or  pointers,  the  system  can  not  be 
represented  using  the  GIM.  This  is  not  unreasonable  for  the  FORTRAN  language,  but  is 
a  limitation  for  languages  such  as  C  or  Pascal.  The  GIM  is  easily  extended  by  adding  new 
ASTs  to  represent  the  new  constructs  and  by  defining  formal  semantics  for  them  using 
weakest  preconditions. 

Overall,  the  GIM  provides  a  canonical  form  for  representing  imperative  programs. 
The  GIM  is  used  throughout  the  following  chapters  to  represent  subprograms  that  are 
being  converted  from  the  imperative  paradigm  to  the  object-oriented  paradigm. 
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IV.  The  Generic  Object  Model 

4.1  Introduction 

This  chapter  defines  the  Generic  Object-Oriented  Design  Model  (GOM)  which  has 
been  developed  to  model  the  objects,  classes,  methods,  and  messages  typically  built  as  part 
of  an  object-oriented  programming  language.  A  general  discussion  of  the  object-oriented 
paradigm  is  presented  first,  followed  by  detailed  descriptions  of  how  the  entities  in  this 
paradigm  are  modeled  using  abstract  syntax  trees  (ASTs).  The  classes  that  define  the 
GOM  ASTs  are  presented  using  Rumbaugh’s  OMT  notation  [62].  The  formal  semantics 
of  the  program  constructs  are  defined  using  the  weakest  precondition  notation. 

In  order  to  scope  this  research,  the  GOM  was  built  to  model  00  languages  that  use 
sequences  of  imperative  statements  in  the  methods.  Usually  these  languages  started  in  the 
imperative  paradigm  and  00  extensions  were  added  in  new  versions  of  the  languages,  e.g. 
Ada  95  and  C-f- 1-.  For  this  reason,  imperative  assignment,  sequential  control,  selective 
control,  and  iterative  control  constructs  are  included  in  the  GOM.  These  constructs  must 
be  adapted  for  use  in  the  GOM  because  GOM  expressions  now  include  accesses  to  object 
attributes  (as  explained  in  Section  4.6)  and  possibly  messages  to  other  objects  (as  explained 
in  Section  4.8). 

Since  the  GOM  provides  a  canonical  form  for  representing  object-oriented  languages, 
00  languages  such  as  Ada  95,  C+-1-,  and  Java  can  be  modeled  using  the  GOM.  Since  the 
focus  of  this  research  was  to  produce  an  OO  design,  no  attempt  was  made  to  recover  GOM 
ASTs  from  00  code.  Instead,  rudimentary  transformations  from  the  GOM  to  Ada  95 
were  developed  as  a  proof-of-concept  prototype.  This  prototype  research  is  discussed  with 
the  feasibility  demonstration  in  Chapter  VIII.  For  these  reasons,  throughout  the  rest  of 
this  chapter,  examples  are  given  that  have  more  of  a  forward  engineering  flavor  (from  the 
GOM  to  a  specific  language)  than  a  reverse  engineering  flavor  (from  an  00  language  to 
the  GOM). 

In  order  to  visualize  the  ASTs  built  in  the  GOM,  a  surface  syntax  has  been  developed 
for  each  entity  in  the  GOM.  The  surface  syntax  is  termed  the  Generic  Object-Oriented 
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Language  (GOL)  and  is  shown  in  Appendix  B.  The  GOL  was  built  only  as  a  tool  for  viewing 
the  GOM  ASTs  and  is  not  intended  as  a  new  object-oriented  programming  language. 

4-2  The  Object-Oriented  Paradigm 

As  discussed  in  Chapter  III,  the  object-oriented  paradigm  is  one  of  the  four  program¬ 
ming  language  paradigms  [16].  Korson  and  McGregor  [38]  characterize  the  object-oriented 
paradigm  using  the  following  concepts; 


Classes  A  class  is  a  template  that  defines  the  attributes  and  operations  for  each 
instance  of  the  class. 

Objects  An  object  is  an  instance  of  a  class.  Objects  model  real-world  entities  that 
have  state,  behavior,  and  identity. 

Methods  A  method  is  a  sequence  of  object-oriented  statements  that  implement  a 
specific  behavior. 

Messages  A  message  invokes  a  specific  method  in  an  object.  Messages  are  sent  to 
a  target  object  that  must  be  able  to  execute  the  method  being  invoked. 

Inheritance  The  classes  in  an  object-oriented  design  are  organized  in  a  class  hier¬ 
archy  where  certain  classes  inherit  the  attributes  and  operations  from  other  classes 
in  the  hierarchy. 

Polymorphism  In  an  object-oriented  design,  it  is  possible  to  have  methods  (from 
different  classes)  with  the  same  name.  Polymorphism  means  the  appropriate  method 
will  be  executed  based  on  the  class  of  an  object  instance. 

The  GOM  provides  a  canonical  form  for  modeling  each  of  these  aspects  of  object- 
oriented  languages.  The  object-oriented  statements  in  each  method  in  the  GOM  are  as¬ 
sumed  to  be  based  on  imperative  control  flow  constructs.  It  is  also  assumed  that  one  special 
method  is  given  the  flow  of  control  as  the  object-oriented  system  begins  execution.  This 
special  method  is  termed  the  main  method.  The  following  sections  define  the  ASTs  that 
store  the  knowledge  about  these  entities.  Where  applicable,  the  formal  semantics  of  these 
entities  is  also  defined. 

Because  of  the  intertwining  of  the  aspects  of  the  00  paradigm,  it  is  hard  to  present 
them  in  an  order  that  does  not  include  any  forward  references  to  other  aspects.  Because  of 
this,  it  is  assumed  that  the  reader  has  a  rudimentary  understanding  of  the  Object-Oriented 
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paradigm  as  aspects  of  the  GOM  are  discussed.  There  are  several  good  references  that 
explain  the  00  paradigm  in  great  detail,  and  the  reader  is  referred  to  them  [9,10,38,62]. 

4-3  The  GOM  Domain  Model 

This  section  presents  a  brief  overview  of  the  ASTs  that  are  included  in  the  GOM 
domain  model.  Figure  50  shows  a  partial  representation  of  the  GOM  domain  model.  The 


GOM-Entity 


Figure  50  GOM  Domain  Model 

overall  superclass  of  the  domain  is  the  GOM-entity  AST.  The  GOM-design  class  mod¬ 
els  collections  of  classes  as  defined  in  Section  4.5.  The  abstract  class  GOM-statement  is 
the  superclass  for  all  object-oriented  programming  statements  modeled  in  the  GOM.  The 
GOM-data-construct  class  is  the  superclass  of  object-oriented  expressions,  data  types, 
attribute  accesses,  functional  messages,  and  variables  modeled  in  the  GOM.  Each  of  the 
lower-level  classes  in  the  GOM  domain  model  are  described  in  the  rest  of  this  chapter. 

4-4  Classes 

In  the  00  paradigm,  classes  define  templates  for  objects.  They  define  the  attributes 
each  instance  of  the  class  will  have  and  store  the  behavior  each  instance  is  capable  of 
executing.  Classes  are  modeled  in  the  GOM  using  the  gom-class  class.  Figure  51  shows 

gom-class 

gom-name :  symbol 
gom-attrs :  set(gom-attribute) 
gom-opers :  set(gom-method) 
gom-super :  symbol 

Figure  51  GOM  Class  Class 
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the  class  description  for  the  gom-class  class.  The  gom-name  attribute  holds  a  symbol 
that  represents  the  name  of  the  class.  The  gom-attrs  attribute  of  this  class  holds  the 
attributes  of  classes  being  modeled  in  the  GOM.  The  gom-opers  attribute  of  this  class 
holds  the  methods  for  the  class  being  modeled.  The  gom-super  attribute  holds  the  symbol 
representing  the  superclass  from  which  this  class  inherits.  The  symbol  USER-OBJECT  is  pro¬ 
vided  to  represent  the  overall  superclass  at  the  root  of  the  class  hierarchy.  As  an  example, 

class  CLASS-5  attributes  RHOSTD,  LAMBDA,  ANGFAC 
method  RHO  (  C-5  ) :  real 
begin 

RHO  :=  GET-RHOSTD  (  C-5) 
end 

superclass  USER-OBJECT 

Figure  52  Class  CLASS-5 

Figure  52  shows  the  class  CLASS-5  (using  COL  syntax).  This  class  has  three  attributes 
named  RHOSTD,  LAMBDA,  and  ANGFAC  and  one  method  named  RHO.  The  class  inherits  from 
the  super  class  USER-OBJECT.  Figure  53  shows  how  the  class  CLASS-5  is  modeled  in  the 


Figure  53  GOM  Class  Object 


GOM.  The  attributes  RHOSTD,  LAMBDA,  and  ANGFAC  are  stored  in  the  gom-attrs  attribute. 
The  method  RHO  is  stored  in  the  gom-opers  attribute.  The  USER-OBJECT  symbol  is  stored 
in  the  gom-super  attribute  to  represent  the  fact  that  this  class  inherits  from  the  class 
named  USER-OBJECT. 
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Each  class  in  the  00  paradigm  must  be  able  to  instantiate  instances  of  the  class. 
The  gom-instantiate  object  is  used  to  model  this  ability  of  a  class.  Since  almost  every 
00  language  has  a  unique  way  to  instantiate  an  instance  of  a  class,  the  gom-insteintiate 
object  provides  a  canonical  form  for  modeling  object  instantiation.  Figure  54  shows  the 

gom-instantiate 
gom-inst-class :  symbol 

Figure  54  GOM  Instantiate  Class 

class  description  for  the  gom-instantiate  object.  The  gom-inst-class  attribute  holds  a 
symbol  representing  the  name  of  the  class  being  requested  to  instantiate  a  new  instance. 
The  GOL  surface  syntax  for  this  class  is  the  keyword  new  followed  by  the  value  of  the 
gom-inst-class  attribute.  The  gom-instantiate  class  models  the  intrinsic  behavior  of 
a  class  to  create  new  instances.  As  with  OO  objects  being  modeled,  there  is  no  need  to 
define  formal  semantics  for  00  classes  being  modeled.  Classes  do  not  directly  affect  the 
state  of  the  00  system. 

4-5  Modeling  Object-Oriented  Designs 

In  order  to  model  the  collection  of  classes  in  an  00  design  as  a  whole,  classes  are 
stored  in  an  AST  built  from  the  GOM  class  gom-design.  An  instance  of  the  gom-design 
class  stores  all  the  classes  in  the  class  hierarchy  defined  for  a  specific  object-oriented  design. 
Figure  55  shows  the  class  description  of  the  gom-design  class.  The  gom-classes  attribute 

gom-design 

gom-classes :  seq(gom-class) 
gom-files :  seq(gom-file) 

Figure  55  GOM  Design  Class 

holds  the  collection  of  classes  that  comprise  the  design.  The  gom-files  attribute  holds 
the  collection  of  input/output  files  being  modeled  for  this  design.  See  Section  4.26  and 
Section  4.27  for  discussions  of  how  input  and  output  statements  and  files  are  modeled  in 
the  GOM. 
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4-6  Objects 


The  basic  building  block  for  the  object-oriented  paradigm  is  the  object.  An  object 
has  state,  behavior,  and  identity  [9].  Objects  are  modeled  in  the  GOM  by  using  variables 
whose  data  type  refers  to  a  class.  The  variable  is  the  handle  into  the  object  and  is  used  to 
access  the  attributes  of  the  object  and  to  receive  messages  from  other  objects.  Variables 
are  discussed  in  Section  4.18,  but  an  example  of  a  variable  used  to  model  an  object  is 
presented  here  for  clarity.  Figure  56  shows  an  example  of  a  variable  that  models  an  object 


(gom-variable) 

gom-name  =  C-15 
gom-var-scope  =  PRDIV 
gom-indices  =  [  ] 
gom-var-type  =  CLASS- 1 


Figure  56  An  Object  Instance  Variable 


instance  built  from  class  CLASS- 1.  This  variable  is  modeled  by  building  an  AST  from 
the  class  gom-variable.  In  the  figure,  the  gom-name  attribute  holds  the  symbol  C-15 
which  models  the  identifier  for  the  variable.  The  variable  is  referenced  by  this  identifier  in 
GOM  statements  to  provide  access  to  the  object  and  its  attributes.  The  gom-var-scope 
in  this  example  holds  the  symbol  PRDIV  to  represent  the  fact  that  this  variable  is  declared 
in  the  scope  of  the  PRDIV  method.  Scoping  issues  for  GOM  variables  are  discussed  in 
Section  4.21.  The  gom-var-type  attribute  is  set  to  the  data  type  gom-instemce  which 
indicates  the  variable  is  an  instance  of  CLASS-1.  For  simplicity,  the  fact  that  C-15  is  an 
instance  of  CLASS-1  is  represented  in  the  figure  by  using  a  symbol. 

Each  object  from  an  OO  program  is  an  instance  of  a  class,  which  defines  the  at¬ 
tributes  of  the  object.  Each  object  has  a  copy  of  these  attributes  defining  a  separate  state 
space  for  each  object  instance.  Each  OO  programming  language  provides  a  way  to  access 
these  attributes  of  the  object.  The  access  of  an  object  attribute  is  modeled  in  the  GOM  by 
the  gom-attr-access  class.  Figure  57  shows  the  class  definition  for  the  gom-attr-access 
class.  The  gom-tar-object  attribute  holds  the  variable  representing  the  target  object 
whose  attribute  is  being  accessed.  The  gom-attrib  attribute  holds  the  variable  represent¬ 
ing  the  name  of  the  attribute  to  be  accessed.  For  example.  Figure  58  shows  an  access 
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gom-attr-access 

gom-tar-object :  gom-variable 
gom-attrib ;  gom-variable 


Figure  57  Attribute  Access  Class 


(gom-attr-access) 


gom-tar-object 


gom-attrib 


f  (gom-variable)  \ 

f  (gom-attribute)  \ 

gom-name  =  C-1 

gom-name  =  A 

gom-var-scope  =  PRDIV 

gom-var-scope  =  CLASS- 1 

gom-var-type  =  CLASS- 1 

gom-var-type  =  gom-real 

gom-indices  =  [  ]  , 

gom-indices  =  [  ]  , 

Figure  58  Attribute  Access  Object. 


of  the  attribute  A  of  the  object  C-1.  The  GOL  surface  syntax  for  this  attribute  access  is 
C-l.A,  thus  C-1  is  the  GOM  variable  holding  the  target  object  and  A  is  the  name  of  the 
attribute  being  accessed. 

There  is  no  need  to  define  formal  semantics  for  00  objects  being  modeled  in  the 
GOM.  Objects  hold  pieces  of  the  state  of  an  OO  system,  but  they  do  not  change  the  state 
directly.  The  programming  language  statements  in  the  methods  of  objects  do  change  the 
state  and  formal  semantics  for  these  statements  are  defined  in  the  sections  that  describe 
how  these  statements  are  modeled. 


J^.1  Methods 

A  method  in  the  00  paradigm  is  a  named  sequence  of  object-oriented  programming 
language  statements  that  is  stored  in  a  class.  The  statements  that  are  modeled  in  the  GOM 
include  assignment,  sequential  control  flow,  selective  control  flow,  iterative  control  flow,  and 
subprogram  invocation  of  non-user-defined  subprograms.  A  method  has  formal  parameters 
and  may  or  may  not  return  a  value.  Methods  are  modeled  in  the  GOM  using  ASTs  built 
from  the  gom-method  class.  Figure  59  shows  the  class  description  for  the  gom-method 
class.  The  gom-name  attribute  stores  a  symbol  representing  the  name  of  the  method.  The 
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gom-method 

gom-name :  symbol 
gom-params :  seq(gom-parameter) 
gom-stmts ;  seq(gom-program-construct) 
gom-retum-type :  gom-data-type 

Figure  59  GOM  Method  Class 

gom-params  attribute  stores  the  formal  parameters  of  the  method.  Each  formal  parameter 
is  a  GOM  variable.  The  number,  order,  and  type  of  these  parameters  is  important  for 
consistency  and  is  always  maintained.  The  gom-stmts  attribute  models  the  sequence 
of  programming  language  constructs  that  comprise  the  method.  The  gom-return-type 
attribute  models  the  return  type  (if  any)  of  the  method.  If  the  method  does  not  return  a 
value,  then  this  attribute  is  undefined. 

class  CLASS-5  attributes  RHOSTD,  LAMBDA,  ANGFAC 
method  RHQ  (  C-5  ) :  real 
begin 

RHO  :=  GET-RHOSTD  (  C-5) 
end 

superclass  USER-OBJECT 

Figure  60  Class  CLASS-5 

For  example.  Figure  60  shows  the  class  CLASS-5  (using  COL  syntax).  CLASS-5  has 
a  single  method  named  RHO.  This  method  has  one  formal  parameter,  C-5,  which  is  the 
target  object  of  the  method  and  an  instance  of  CLASS-5.  The  RHO  method  returns  a  value 
of  type  gom-real  and  has  one  statement  in  the  body  of  the  method.  Figure  61  shows  how 
the  RHO  method  is  represented  using  a  gom-method  AST.  The  name  of  the  method,  RHO,  is 
stored  in  the  gom-name  attribute,  the  formal  parameter  C-5  is  stored  as  the  only  element 
of  the  gom-params  attribute^.  The  single  statement  is  stored  in  the  gom-stmts  attribute. 

Methods  in  the  OO  paradigm  are  analogous  to  imperative  subprograms.  Methods 
that  return  a  value  after  execution  are  similar  to  imperative  functions.  This  kind  of  method 

^For  simplicity,  the  fact  that  C-5  is  an  instance  of  CLASS-5  is  represented  in  this  diagram  by  using  a 
symbol. 
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(gom-method) 
gom-name ;  RHO 
gom-retum-type :  gom-real 


gom-params 


gom-statements 


(gom-variable) 
gom-name :  C-5 
gom-var-scope :  RHO 
gom-var-type :  CLASS-5 
gom-indices :  [  ] 


(gom-assignment) 


Figure  61  GOM  Method  Object 


is  referred  to  in  the  rest  of  this  document  as  a  functional  method.  Methods  that  do 
not  return  a  value  after  execution,  but,  instead,  communicate  through  input  and  output 
parameters  are  similar  to  imperative  procedures.  This  kind  of  method  is  referred  to  in 
the  rest  of  this  document  as  a  procedural  method.  Both  methods  and  subprograms  define 
formal  parameters  where  the  number,  order,  and  type  of  the  parameters  must  be  matched 
by  the  actual  parameters  in  a  message  or  a  subprogram  call,  respectively. 

Because  methods  in  the  GOM  are  built  from  subprograms  in  the  GIM,  certain  prop¬ 
erties  of  GIM  subprograms  are  carried  forward  in  the  transformation  and  now  apply  to 
GOM  methods.  Specifically,  for  both  functional  and  procedural  GOM  methods,  the  fol¬ 
lowing  restriction  applies. 

Restriction  IV.l.  A  formal  parameter  of  a  method  must  not  be  both  an  input  and  an 
output  parameter. 

For  functional  methods,  the  following  restriction  applies. 

Restriction  IV.2.  All  functional  methods  must  return  a  single  value  at  the  end  of  their 
execution  and  have  no  output  parameters. 

As  with  GIM  subprograms,  the  declaration  of  a  GOM  method  does  not  change  the 
state  of  a  program.  A  message  that  invokes  the  method  is  allowed  to  change  the  state,  thus 
the  formal  semantics  for  method  declarations  provided  in  this  section  serve  as  a  foundation 
for  the  definition  of  the  formal  semantics  of  messages. 
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Given  a  precondition  P,  a  postcondition  R,  and  a  sequence  of  00  statements  51,  it 


is  assumed  that  P  and  R  exist  such  that  the  following  holds. 

51 

{R} 

For  a  method  m,  let  x  be  a  vector  representing  the  input  parameters  of  m.  Let  2  be  a 
vector  representing  the  output  parameters  of  m.  A  procedural  GOM  method  takes  the 
following  general  form. 

method  m(x,  z) 

{P} 

51 

{R} 

A  functional  GOM  method  takes  the  following  general  form. 

method  m{x) 

{P} 

51 

{R} 


In  order  to  define  the  semantics  for  the  value  that  is  returned  from  the  method  m,  a 
modified  representation  is  used.  Let  y  represent  the  value  that  is  returned  from  m.  Let 
m'  be  a  method  that  takes  the  same  input  parameters  as  m,  and  includes  y  as  the  single 
output  parameter.  The  statements  in  m'  are  the  statements  from  m,  viz.  51.  The  method 
m'  takes  the  following  form. 

method  m'{x,  y) 

{P} 

51 

{R} 

These  general  forms  define  the  formal  semantics  for  method  declarations  in  the  GOM.  To 
tie  this  general  form  to  the  specific  representation  in  the  GOM,  recall  that  the  sequence  of 
00  statements,  51,  in  the  method  is  modeled  by  the  gom-stmts  attribute  in  the  GOM. 
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4-8  Messages 

In  the  OO  paradigm,  objects  communicate  by  sending  messages.  Messages  are  re¬ 
quests  from  one  object  (the  sending  object)  to  another  object  (the  target  object).  If  the 
target  object  has  a  method  that  corresponds  to  the  message  received,  then  the  target  ob¬ 
ject  executes  this  method.  Messages  have  actual  parameters  that  must  match  in  number, 
order,  and  type  to  the  formal  parameters  of  the  requested  method. 

Rumbaugh  [62]  describes  the  abstract  notion  of  flow  of  control  in  the  OO  paradigm 
as  a  collection  of  concurrently-active  objects  sending  messages  to  each  other.  Rumbaugh 
uses  state  diagrams  in  his  dynamic  model  to  represent  this  interaction  of  objects.  Since 
the  GOM  was  built  to  model  OO  languages  that  use  sequences  of  imperative  statements  in 
their  methods,  flow  of  control  in  the  GOM  is  modeled  using  a  procedure-driven  approach 
versus  using  concurrent  tasks.  Speciflcally,  flow  of  control  is  passed  from  the  sending  object 
to  the  target  object  when  the  message  is  sent,  and  it  is  returned  to  the  sending  object  when 
the  method  completes  execution. 

Messages  are  modeled  in  the  GOM  by  using  instances  of  the  gom-message  class. 
Figure  62  shows  the  class  description  for  the  gom-message  class.  The  gom-call  attribute 

gom-message 

gom-call :  symbol 
gom-actuals ;  seq(gom-variable) 

Figure  62  GOM  Message  Class 

stores  a  symbol  representing  the  name  of  the  method  to  be  executed  in  the  target  object. 
The  gom-actuals  attribute  stores  the  sequence  of  GOM  variables  that  represent  the  actual 
parameters  of  the  method.  The  first  parameter  in  the  sequence  of  actual  parameters  is 
always  the  target  object.  For  example,  consider  the  following  assignment  statement  (shown 
in  GOL  syntax). 

SIGTRB  :=  RHO  (  C-7) ; 

This  assignment  statement  includes  a  message  that  invokes  the  RHO  method  shown  in 
Figure  60.  Figure  63  shows  how  the  message  is  represented  using  an  AST  built  from  the 
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(gom-message) 
gom-call :  RHO 


gom-actuals 


(gom-variable) 
gom-name :  C-7 
gom-var-scope :  BOUNCE 
gom-var-type :  CLASS-5 
gom-indices :  [  ] 


Figure  63  GOM  Message  Object 

gom-message  class.  The  gom-call  attribute  is  set  to  the  symbol  RHO  to  indicate  the  name 
of  the  method  to  be  invoked.  The  gom-actuals  attribute  holds  the  sequence  with  the 
single  actual  parameter  C-7.  This  parameter  is  represented  as  a  GOM  variable  which  is 
named  C-7,  is  in  the  scope  of  PRDIV,  and  is  an  instance  of  CLASS-5^.  Since  C-7  is  the  first 
parameter  of  the  message,  it  is  the  target  object. 

Messages  in  the  00  paradigm  are  analogous  to  subprogram  calls  in  the  imperative 
paradigm.  A  message  that  invokes  a  functional  method  is  similar  to  a  function  call.  This 
kind  of  message  is  referred  to  in  the  rest  of  this  document  as  a  functional  message.  Func¬ 
tional  messages  are  a  kind  of  00  expression,  i.e.  they  do  not  comprise  a  statement  on 
their  own.  A  message  that  invokes  a  procedural  method  is  similar  to  a  procedure  call. 
This  kind  of  message  is  referred  to  in  the  rest  of  this  document  as  a  procedural  message. 
Procedural  messages  are  a  kind  of  OO  statement. 

The  semantics  of  messages  in  the  GOM  are  defined  using  the  weakest  precondition 
notation  as  well  as  the  general  form  of  method  declarations  defined  in  Section  4.7.  Let  m 
be  a  procedural  method,  and  let  ^  be  a  procedural  message  that  invokes  m.  Let  a  be  a 
vector  representing  the  actual  parameters  that  correspond  to  input  parameters  in  m.  Let 
c  be  a  vector  representing  the  actual  parameters  that  correspond  to  output  parameters  in 
m.  The  message  g  takes  the  form 


m(a,  c) 


^For  simplicity,  this  instance  of  CLASS-5  is  represented  in  this  figure  as  the  symbol  CLASS-5 
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As  defined  in  Section  4.7,  the  gom-stmts  attribute  of  a  GOM  method  declaration  models 
a  sequence  of  GOM  statements.  Let  51^  be  this  sequence  of  statements  from  the  method 
m.  Recall  from  Section  4.7  that  x  is  a  vector  representing  the  input  parameters  of  m, 
and  z  is  a  vector  representing  the  output  parameters  of  m.  When  a  message  is  sent  to  an 
object,  the  formal  parameters  of  the  method  being  requested  are  set  to  the  values  of  the 
actual  parameters  from  the  message.  The  method  corresponding  to  the  message  sent  is 
then  executed.  Formally,  this  is  equivalent  to  executing  the  following  sequence. 

[x  :=  a,  Sim,  c  := 

Using  weakest  precondition  notation,  the  semantics  for  the  message  g  is  defined  as  follows. 

Definition  IV.l.  wp{m{a,c),R)  =  wp{[x  :=  a,  Slm,c  :=  z],  R) 

The  formal  semantics  for  functional  messages  are  defined  more  restrictively  as  follows. 
Let  m  be  a  functional  method,  let  51  be  the  sequence  of  statements  declared  in  m,  and 
let  5  be  a  functional  message  that  invokes  m.  Let  6  be  a  vector  representing  the  actual 
parameters  that  correspond  to  input  parameters  in  m.  Since  every  such  method  appears  as 
part  of  an  expression  in  some  statement,  let  5  represent  the  statement  in  which  m  appears. 
Recall  the  modified  representation  of  a  method  presented  in  Section  4.7  includes  one  output 
parameter,  y,  which  represents  the  value  returned  from  m.  Let  m'  be  the  method  that 
represents  m  with  the  formal  parameters  from  m  and  the  additional  parameter  y.  Let  b 
represent  the  actual  parameter  that  corresponds  to  y. 

Using  these  definitions,  the  invocation  of  m  takes  the  following  form. 

m(a) 

The  invocation  of  the  method  m!  takes  the  following  form. 

m'{a,y) 

The  difference  between  the  invocations  of  m  and  m'  is  that  the  invocation  of  m  is  part  of  5 
and  the  invocation  of  m'  is  a  single  statement.  Invoking  m  is  equivalent  to  invoking  m'  and 
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then  substituting  6  in  5  for  any  invocations  of  m.  This  provides  a  formal  representation 
of  the  value  returned  from  m.  The  substitution  of  b  for  the  call  to  m  in  5  is  represented 
by  the  following  notation. 


Qm(a) 

In  this  way,  the  call  to  m  is  equivalent  to  the  following  sequence  of  statements. 

[m'(a,  6), 

When  the  method  m'  is  invoked,  the  formal  parameters  of  m'  are  set  to  a  and  the 
statements  in  51  are  executed.  After  execution,  the  parameter  b  is  set  to  the  value  y. 
Formally,  the  invocation  of  m'  is  equivalent  to  executing  the  following  sequence. 


[a;  :=  a,51,6  :=  y] 


Using  weakest  precondition  notation,  the  formal  semantics  for  the  message  g  are  defined 
as  follows. 

Definition  IV.2.  wp{m{a),  R)  =  wp{[x  a,  Sl,b  :=  y,  R) 

4.9  “GET-”  and  “SET-”  Messages 

In  order  to  provide  a  better  encapsulation  of  extracted  objects,  the  following  restric¬ 
tion  applies. 

Restriction  IV.3.  Object  attributes  are  accessed  and  assigned  values  only  through  “GET-” 
and  “SET-”  messages  sent  to  the  object. 

Figure  64  shows  the  GET-ZCOS  and  SET-ZCOS  methods  used  for  accessing  and  assign¬ 
ing  a  value  to  the  ZCOS  attribute. 

The  general  form  of  a  “SET-”  message  is 

SET-a(r,  e) 
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method  GET-ZCOS  (  C-10  ) :  real 
begin 

GET-ZCOS  :=  C-IO.ZCOS 
end 

method  SET-ZCOS  (  C-11,  VAL-10  ) 
begin 

C-ll.ZCOS  :=  VAL-10 
end 

Figure  64  “SET-”  and  “GET-”  Methods  for  ZCOS 

where  a  is  the  name  of  the  attribute  being  assigned  a  value,  r  is  the  target  object,  and  e  is 
the  expression  to  which  the  attribute  a  is  set.  The  formal  semantics  for  a  “SET-”  message 
are  defined  using  the  weakest  precondition  notation.  Given  a  postcondition  R,  let 
represent  R  with  all  free  occurrences  of  the  attribute  a  from  r  simultaneously  replaced 
with  e.  The  semantics  for  the  general  form  of  the  “SET-”  message  are  defined  below. 

Definition  IV.3.  wp{SET-a{T,  e),  R)  = 

The  general  form  of  a  “GET-”  message  is  shown  below. 

GET-a(r) 

Here,  a  is  the  name  of  an  attribute  being  accessed  and  r  is  the  target  object.  The  “GET-” 
message  for  an  attribute  returns  the  value  of  the  attribute  a  from  the  target  object  r. 
Since  the  “GET-”  message  is  returning  a  value,  it  is  similar  to  a  function  invocation  from 
the  imperative  paradigm.  Because  of  this  similarity,  the  formal  semantics  for  a  “GET-” 
message  are  defined  using  a  modified  version  of  the  “GET-”  method.  The  modified  version 
includes  a  single  output  parameter,  y,  which  represents  the  value  returned  from  the  “GET- 
”  method.  Let  b  represent  the  actual  parameter  that  corresponds  to  the  formal  parameter 
y.  The  invocation  of  the  modified  “GET-”  method  takes  the  following  form. 

GET-a(r,6) 
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The  execution  of  this  modified  “GET-”  message  is  equivalent  to  executing  the  following 
sequence. 


[y  :=  T.a,  b  :=  y] 

As  with  function  invocation,  the  value  of  b  replaces  the  original  “GET-”  message  in  the 
statement  that  includes  it.  Let  S  be  the  statement  that  includes  the  “GET-”  message. 
Let  represent  the  textual  substitution  of  b  for  each  occurrence  of  the  “GET-a” 

message  in  the  statement  S.  The  formal  semantics  of  a  “GET-”  message  are  defined  as 
follows. 

Definition  IV.4.  wp(GET-a(T),  R)  =  wp{[y  :=  T.a,  b:—y,  R) 

The  “GET-”  and  “SET-”  methods  for  each  attribute  of  each  class  in  the  object- 
oriented  design  must  be  provided  before  the  design  can  be  implemented.  This  research 
provides  a  transformation,  k,  in  Section  6.11.2  which  formalizes  the  automatic  generation 
of  these  methods  and  their  addition  to  the  set  of  operations  for  each  class  in  the  design. 

4.10  Inheritance 

In  the  GOM,  the  collection  of  classes  in  an  object-oriented  design  is  modeled  as  a 
class  hierarchy  where  certain  classes  inherit  the  attributes  and  operations  from  one  or  more 
other  classes.  This  concept  of  inheritance  is  represented  in  the  GOM  by  the  gom-super 
attribute  of  ASTs  built  from  the  gom-class  class.  The  gom-super  attribute  indicates  from 
which  class  a  specific  class  inherits. 

class  CLASS-5  attributes  RHOSTD,  LAMBDA,  ANGFAC 
method  RHO  (  C-5  ) :  real 
begin 

RHO  :=  GET-RHOSTD  (  C-5) 
end 

superclass  USER-OBJECT 

Figure  65  CLASS-5  inherits  firom  USER-OBJECT 


86 


For  example,  Figure  65  shows  the  class  CLASS-5  (using  GOL  syntax).  CLASS-5  inher¬ 
its  from  the  class  named  USER-OBJECT.  To  represent  inheritance,  the  gom-super  attribute 
holds  the  symbol  that  represents  the  name  of  the  class  from  which  this  class  inherits. 

4-11  Polymorphism 

There  is  support  for  modeling  polymorphism  in  the  GOM,  i.e.  declaring  methods 
with  the  same  name  in  different  classes  is  allowed.  This  support  is  rather  rudimentary 
because  the  concept  of  an  abstract  class  is  not  supported  by  the  GOM.  By  including  abstract 
classes  in  the  GOM,  it  would  be  possible  to  model  class-wide  operations  as  implemented 
by  the  Ada  95  language. 

4.12  Object-Oriented  Assignment 

Several  imperative  programming  language  constructs  appear  in  the  GOM  including 
the  assignment  construct.  As  discussed  in  Section  3.3,  assignment  takes  the  general  form 
of  X  :=  e,  where  x  is  a  variable  and  e  is  an  expression.  The  object-oriented  version  of 
the  assignment  construct  now  allows  x  to  be  an  attribute  access,  which  models  the  way 
attributes  of  objects  are  assigned  values.  The  expression  e  is  also  allowed  to  be  an  attribute 
access  or  a  message  to  another  object.  OO  assignment  statements  are  modeled  in  the  GOM 
using  instances  of  the  gora-assignment  class.  Figure  66  shows  the  class  description  for  the 

gom-assignment 

gom-assign-lhs :  gom-variable 
gom-assign-rhs :  gom-data-construct 

Figure  66  GOM  Assignment  Class 

gom-assignment  class.  The  gom-assign-lhs  attribute  models  the  variable  or  attribute 
being  assigned  a  value,  i.e.  x.  The  gom-assign-rhs  attribute  models  the  expression  e. 

For  example,  consider  the  following  assignment  statement  (shown  using  GOL  surface 
syntax). 

SIGTRB  :=  RHO  (  C-7) 
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This  assignment  statement  assigns  the  value  returned  from  the  RHO  message.  Figure  67 


Figure  67  GOM  Assignment  Object 


shows  the  AST  built  to  model  this  assignment  statement.  The  gom-assign-lhs  attribute 
models  the  GOM  variable  SIGTRB,  which  is  in  the  scope  of  PRDIV,  and  is  of  type  gom-real. 
The  gom-assign-rhs  attribute  models  the  RHO  message  which  returns  a  value  of  type 
gom-real  (see  Figure  63). 

The  formal  semantics  for  an  OO  assignment  statement  are  defined  using  the  weakest 
precondition  notation.  Given  a  postcondition  R,  let  represent  R  with  all  free  occur¬ 
rences  of  X  simultaneously  replaced  with  e  [19].  The  semantics  for  the  general  form  of  the 
GOM  assignment,  x  =  e  are  defined  below. 

Definition  IV.5.  wp(x  :=  e,  R)  =  J?® 

To  relate  these  semantics  to  the  GOM,  note  that  the  gom-assign-lhs  attribute 
models  x  and  the  gom-assign-rhs  models  e. 

4-13  Object-Oriented  Sequential  Control 

As  in  the  imperative  paradigm,  the  default  control  mechanism  for  executing  state¬ 
ments  in  the  OO  paradigm  is  sequential  control.  When  methods  are  being  executed,  the 
statements  are  executed  one  after  another  in  a  sequential  manner.  As  in  the  GIM,  sequen¬ 
tial  control  flow  is  modeled  in  the  GOM  by  storing  the  statements  to  be  executed  in  a 
sequence.  The  order  of  the  sequence  indicates  the  order  in  which  the  statements  are  to  be 
executed. 

For  example,  in  the  collection  of  statements  shown  below,  <00  Statement  1>  is 
executed  first  followed  by  <00  Statement  2>  followed  by  <00  Statement  3>. 

<00  Statement  1>  <00  Statement  2>  <00  Statement  3> 
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This  collection  of  statements  is  modeled  in  the  GOM  using  the  following  sequence. 

[  <00  Statement  1>,  <00  Statement  2>,  <00  Statement  3>  ] 

The  formal  semantics  for  sequential  control  flow  are  deflned  using  the  weakest  pre¬ 
condition  notation.  Let  51  and  52  be  statements,  then  the  semantics  for  the  sequential 
composition  of  these  two  statements  in  the  GOM  is  defined  below. 

Definition  IV.6.  tap([51,52],  R)  =  wp(Sl,  wp(S2,R)) 

The  formal  semantics  of  sequential  control  flow  in  the  GOM  are  identical  to  the 
formal  semantics  of  sequential  control  flow  in  the  GIM.  As  in  the  GIM,  the  representation 
of  sequential  control  flow  in  the  GOM  is  based  on  function  composition  [25],  which  is 
associative,  so  the  GOM  representation  of  sequential  control  flow  is  associative. 

Theorem  IV.l.  u;p([51,  [52,53]],  R)  =  wp{[[Sl,  S2],  S3],  R) 

Proof. 

u;p([51,[52,53]],  il)  =  u)p(51,u;p([52,53],  R)) 

=  wp{Sl,wp{S2,wp{S3,  R))) 

=  u;p([5l,52],rup(53,  R))  (by  function  composition) 

=  u;p([[51,52],53],  R) 


□ 

Since  the  weakest  precondition  for  the  sequences  [51,  [52, 53]]  and  [[51, 52],  53]  are  equal, 
the  sequence  [51, 52,  53]  is  often  used  in  this  document  to  represent  these  sequences.  In 
addition,  singleton  sequences  and  empty  sequences  are  also  used  when  convenient. 

4.14  Object-Oriented  Selective  Control 

As  defined  in  the  imperative  paradigm  (see  Section  3.5),  selective  control  flow  consists 
of  a  selection  between  two  or  more  statements.  Since  the  statements  to  be  executed 
represent  one  or  more  sequentially  composed  statements,  they  are  modeled  as  sequences 
of  statements  in  the  GOM.  Selective  control  flow  constructs  are  modeled  in  the  GOM 
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gom-selection 

gom-exp ;  gom-data-construct 
gom-then-part :  seq(gom-program-construct) 
gom-else-part :  seq(gom-program-construct) 

Figure  68  GOM  Selection  Class 

using  ASTs  built  from  the  gom-selection  class.  Figure  68  shows  the  class  description 
for  the  gom-selection  class.  The  gom-exp  attribute  models  the  OO  expression  that 
controls  which  statements  will  be  executed  by  the  selective  programming  construct.  The 
gom-then-part  models  the  sequence  of  OO  statements  that  are  executed  when  the  OO 
expression  in  gom-exp  is  true.  The  gom-else-part  models  the  sequence  of  statements 
that  will  be  executed  if  the  gom-exp  is  false.  As  in  the  GIM,  51  must  contain  at  least  one 
statement,  but  52  may  be  empty.  ASTs  where  51  and  52  have  at  least  one  statement 
model  object-oriented  if-then-else  statements.  ASTs  where  52  is  empty  model  object- 
oriented  if-then  statements. 

For  example,  the  if-then-else  statement  shown  below  (using  GOL  syntax)  provides 
a  good  example  of  selective  control  flow  in  the  GOM. 

if  GET-SIGTRB  (  C-12)  >0.0  then 

UPLREQ  :=  SIGUP  /  GET-SIGTRB  (  C-12) 
else 

UPLREQ  :=  1000000. OdO 
endif 

This  statement  makes  a  selection  based  on  the  result  of  the  GET-SIGTRB  message,  which  is 
sent  to  the  target  object  C-12.  The  statement  selects  between  two  assignment  statements 
that  assign  values  to  the  variable  UPLREQ.  Figure  69  shows  the  object  instance  that  mod- 


Figure  69  GOM  Selective  Control  Flow  Example 


els  this  GOM  if-then-else  statement.  The  gom-exp  attribute  models  the  greater-than 
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boolean  expression  that  controls  the  selection  and  the  two  assignment  statements  are  mod¬ 
eled  by  the  gom-then-part  and  the  gom-else-part  attributes. 

The  formal  semantics  of  selective  control  flow  in  the  GOM  are  defined  using  the 
weakest  precondition  notation.  Let  B  represent  an  OO  boolean  expression  and  let  51  and 
52  represent  sequences  of  OO  statements.  The  selective  control  flow  constructs  in  the 
GOM  take  the  following  form 

if  B  then  51  else  52 

Recall  that  51  is  executed  if  B  is  true  and  52  is  executed  if  B  is  false.  The  semantics  of 
this  GOM  form  of  selective  control  flow  are  defined  below. 

Definition  IV.7.  wp{\f  B  then  51  else  52,  R)  = 

(B  wp{Sl,R))  A  {~<B  wp{S2,  R)) 

To  relate  these  formal  semantics  to  the  GOM,  note  that  B  is  modeled  using  the 
gom-exp  attribute.  The  sequence  of  statements  51  is  modeled  by  the  gom-then-part 
attribute  and  the  sequence  52  is  modeled  by  the  gom-else-part  attribute.  The  formal 
semantics  for  GOM  selection  is  now  defined. 

As  in  the  imperative  paradigm,  the  formal  semantics  for  selective  control  flow  when 
the  sequence  52  is  empty  are  defined  using  the  skip  command.  Recall  from  Section  3.5 
that  the  formal  semantics  of  the  skip  command  are  typ(skip,  R)  =  R. 

Selective  control  flow  in  the  GOM  when  52  is  empty  takes  the  form 

if  B  then  51  else  skip 

The  formal  semantics  for  this  form  of  selective  control  flow  in  the  GOM  is  defined  below. 
Definition  IV.8.  it;p(if  B  then  51  else  skip,  R)  =  {B  wp{Sl,  R))  A  (-iR  R) 

4-15  Object-Oriented  Iterative  Control 

Iterative  control  flow,  as  defined  in  the  imperative  paradigm  (see  Section  3.6)  is  a 
mechanism  for  repeating  sequences  of  statements.  The  execution  of  a  sequence  of  state- 
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merits  continues  while  some  boolean  expression  is  true.  Iterative  control  flow  in  the  GOM 
is  modeled  using  ASTs  built  from  the  gom- iteration  class.  Figure  70  shows  the  class  de- 

gom-iteration 

gom-iter-exp :  gom-expression 
gom-iter-body :  seq(gom-program-constmct) 

Figure  70  GOM  Iteration  Class 

scription  for  the  gom-iteration  class.  The  gom-iter-expr  attribute  models  the  boolean 
expression  that  controls  the  iteration.  The  gom-iter-body  holds  the  sequence  of  state¬ 
ments  that  are  executed  each  time  through  the  iteration. 

For  example,  the  while  loop  shown  below  (using  GOL  syntax). 

IL  :=  1; 

while  IL  <=  GET-NLASER  (  C-14)  do 
begin 

LLAS  (  IL)  :=  0; 

TLAS  (  IL)  :=  0; 

IL  :=  IL  +  1 
end 

This  while  loop  is  an  example  of  iterative  control  flow  in  the  object  paradigm.  Figure  71 


Figure  71  GOM  Iteration  Object 


shows  the  AST  that  models  this  while  loop  in  the  GOM.  The  gom-ter-exp  attribute 
holds  the  less-than-or-equal  expression  that  controls  the  iteration.  The  gom-iter-body 
holds  the  three  assignment  statements  in  the  body  of  the  loop. 

The  GOM  model  of  iteration  provides  a  canonical  form  for  representing  imperative- 
style  iteration  in  the  object  paradigm.  Several  OO  programming  languages  provide  pro- 
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gramming  constructs  that  implement  iteration  including  the  while  statement  in  C++  and 
the  loop  statement  in  Ada  95.  The  feasibility  demonstration  (see  Chapter  VIII)  provides 
rudimentary  examples  of  converting  certain  GOM  entities  into  Ada  95  code. 

As  with  the  other  control  flow  constructs,  the  formal  semantics  for  iterative  control 
flow  are  deflned  using  the  weakest  precondition  notation.  Given  a  precondition  P  and  a 
postcondition  R,  let  Hk{R)  represent  the  set  of  all  states  in  which 

while  S  do  Si 

will  establish  R  in  at  most  k  iterations  [19].  The  formal  semantics  for  iterative  control  flow 
in  the  GOM  are  deflned  below. 

Definition  IV. 9.  wp{  while  B  do  SI,  R)  =  (3k  :  0  <  fc  A  HkiR)) 

To  tie  this  general  definition  to  the  specific  model  of  iterative  control  flow  in  the 
GOM,  recall  that  B  is  modeled  by  the  gom-iter-exp  attribute  and  SI  is  modeled  by  the 
gom-iter-body  attribute  of  the  gom-iteration  class. 

As  in  the  GIM,  the  task  still  remains  to  define  Hk(R).  There  is  no  attempt  in  this 
research  to  define  loop  invariants  [19]  for  iteration  in  the  GOM.  The  set  of  states  Hk{R) 
defines  the  semantics  of  iteration  in  the  GOM  to  a  level  of  detail  sufficient  for  this  research. 

4-16  Object-Oriented  Subprogram  Invocation 

Even  though  the  primary  means  of  communication  in  the  OO  paradigm  consists 
of  objects  sending  messages  to  each  other,  there  is  still  a  need  to  model  subprogram 
invocations  in  the  GOM.  Specifically,  there  will  still  be  calls  to  utility  subprograms  such  as 
SIN  and  COS  that  must  be  modeled  in  the  GOM.  Since  this  research  involves  re-engineering 
GIM  subprograms  to  the  GOM,  all  user-defined  subprograms  must  be  converted  to  methods 
and  all  calls  to  user-defined  subprograms  must  be  converted  to  messages.  This  leads  to 
the  following  restriction  of  the  GOM. 

Restriction  IV. 4.  Only  calls  to  non-user-defined  subprograms  are  modeled  by  subprogram 
invocations  in  the  GOM. 
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As  in  the  imperative  paradigm,  there  are  two  types  of  subprogram  invocation,  viz. 
procedure  calls  and  junction  calls.  If  the  non-user-defined  subprogram  being  called  is 
a  procedure,  then  the  gom-procedure-call  class  is  used  to  model  the  procedure  call. 
Figure  72  shows  the  class  definition  for  the  gom-procedure-call  class.  The  attribute  gom- 

gom-procedure-call 

gom-proc-call-identifier :  symbol 
gom-proc-call-actuals :  seq(gom-data-constract) 

Figure  72  GOM  Procedure  Call  Class 

proc-call-identifier  holds  a  symbol  that  represents  the  name  of  the  procedure  being 
called.  The  gom-proc-call-actuals  attribute  holds  the  sequence  of  actual  parameters 
sent  to  the  procedure. 

If  the  non- user-defined  subprogram  being  called  is  a  function,  then  the  gom-f  unction- 
call  class  is  used  to  model  the  function  call.  Figure  73  shows  the  class  description  for  the 

gom-function-call 

gom-fun-call-identifier :  symbol 
gom-fun-call-actuals ;  seq(gom-data-construct) 

Figure  73  GOM  Function  Call  Class 

gom-function-call  class.  The  attribute  gom-fun-call-identifier  models  the  name 
of  the  function  being  called.  The  gom-fim-call-actuals  attribute  models  the  actual 
parameters  that  are  passed  to  the  called  function. 

The  formal  semantics  for  calls  to  non-user-defined  procedures  in  the  GOM  are  sim¬ 
ilar  to  the  semantics  for  procedure  calls  in  the  GIM  (see  Section  3.11).  As  in  the  GIM, 
procedures  modeled  in  the  GOM  are  not  allowed  to  have  parameters  that  are  both  in¬ 
put  and  output  parameters,  thus  calls  to  non-user-defined  procedures  must  have  no  such 
parameters. 

Let  p  be  a  non-user-defined  procedure  and  let  SI  be  the  sequence  of  statements 
declared  in  p.  Let  a  be  a  vector  representing  the  actual  parameters  that  correspond  to 
input  parameters  in  p.  Let  c  be  a  vector  representing  the  actual  parameters  that  correspond 


to  output  parameters  in  p.  An  invocation  of  p  takes  the  form: 

p{a,  c) 

To  invoke  p,  the  actual  parameters  are  copied  to  the  formal  parameters  and  control  flow 
transfers  to  p.  Assume  the  vectors  x  and  z  are  the  vectors  representing  the  input  and  output 
parameters  of  the  non-user-deflned  procedure,  respectively.  Executing  the  procedure  call 
p  is  equivalent  to  executing  the  following  sequence 

[5  :=  a,  Si,  c  :=  z] 

Using  weakest  precondition  notation,  the  semantics  for  a  call  to  a  non-user-defined  proce¬ 
dure  are  defined  below. 

Definition  IV. 10.  wp{p(a,c),R)  =  wp^x  a,Sl,c  :=  z],  R) 

The  formal  semantics  for  calls  to  non-user-defined  functions  in  the  GOM  are  similar 
to  the  semantics  for  function  calls  in  the  GIM  (see  Section  3.11).  As  in  the  GIM,  a 
restriction  is  placed  on  functions  as  defined  below. 

Restriction  IV.5.  Non-user-defined  functions  must  have  no  output  parameters. 

Let  /  be  a  non-user-defined  function  and  let  SI  be  the  sequence  of  statements  de¬ 
clared  in  /.  Let  a  be  a  vector  representing  the  actual  parameters  that  correspond  to  the 
input  parameters  in  /.  Since  every  function  appears  as  part  of  an  expression  in  some  state¬ 
ment,  let  S  represent  the  statement  in  which  /  appears.  Recall  the  modified  representation 
of  a  function  presented  in  Section  3.10  includes  one  output  parameter,  y,  which  represents 
the  value  returned  from  the  function  /.  Let  f  be  the  procedure  that  represents  /  with 
the  formal  parameters  from  /  and  the  additional  parameter  y.  Let  b  represent  the  actual 
parameter  that  corresponds  to  y.  Using  these  definitions,  an  invocation  of  the  function  / 
takes  the  following  form. 


/(a) 
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An  invocation  of  the  procedure,  takes  the  following  form. 


The  difference  between  the  invocations  of  /  and  f  is  that  the  invocation  of  /  is  part  of  S 
and  the  invocation  of  f  is  a  single  statement.  Invoking  /  is  equivalent  to  invoking  f  and 
then  substituting  6  in  5  for  any  invocations  of  /.  This  provides  a  formal  representation  of 
the  value  returned  from  /.  The  substitution  of  b  for  the  call  to  /  in  5  is  represented  by 
the  following  notation. 


In  this  way,  the  call  to  /  is  equivalent  to  the  following  sequence  of  statements. 


As  defined  in  Section  3.11,  when  the  procedure  f  is  invoked,  the  actual  parameters  in 
a  are  copied  to  the  formal  parameters  in  x  and  control  flow  transfers  to  /'.  After  execution 
of  the  function,  the  value  of  y  is  copied  to  b.  Hence,  executing  the  call  to  f'  is  equivalent 
to  executing  the  following  sequence. 


[a;  ;=  a,Sl,b:=  y] 


Using  weakest  precondition  notation,  the  formal  semantics  of  a  call  to  the  non-user-defined 
function  /  are  defined  below. 

DefinitionIV.il.  wp{f{a),  R)  =  wp{[x  a,Sl,b  :=  y,  R) 

4-17  Recursion 

In  the  object  paradigm,  it  is  possible  for  a  method  to  send  a  message  that  invokes 
itself,  which  is  termed  recursion.  The  GOM  does  not  model  recursion,  which  leads  to  the 
following  restriction. 


96 


Restriction  IV.6.  Methods  modeled  in  the  GOM  are  not  allowed  to  send  messages  in¬ 
voking  the  method  recursively. 

Even  more  restrictively,  the  call  tree  consisting  of  the  graph  of  messages  sent  between 
objects  is  assumed  to  be  a  directed  acyclic  graph. 

Restriction  IV.7.  The  call  tree  of  messages  sent  between  objects  must  be  a  directed 
acyclic  graph. 

4. 18  Variables 

As  in  the  imperative  paradigm,  variables  are  used  to  store  pieces  of  information  in  the 
object-oriented  paradigm.  Variables  appear  in  OO  programs  as  local  variables  or  formal 
parameters  of  methods.  Local  variables  are  declared  in  the  local  scope  of  a  method  and 
the  value  of  the  variable  is  lost  when  execution  of  the  method  ends.  Formal  parameters  of 
methods  are  variables  that  are  declared  in  the  method  and  used  to  pass  data  items  into 
the  method.  This  section  defines  the  AST  class  used  to  model  variables  in  the  GOM  and 
presents  an  example  of  modeling  a  variable. 

Both  local  variables  and  formal  parameters  are  modeled  in  the  GOM  by  using  the 
gom-variable  class.  Figure  74  shows  the  class  description  for  the  gom-variable  class. 

gom-variable 

gom-name :  symbol 
gom-var-scope :  symbol 
gom-var-type :  gom-data-type 
gom-indices :  seq(gom-data-construct) 

Figure  74  GOM  Variable  Class 

The  gom-name  attribute  holds  a  symbol  that  represents  the  name  of  the  variable.  The 
gom-var-scope  holds  a  symbol  that  represents  the  scope  of  this  variable.  See  Section  4.21 
for  a  discussion  of  scoping  issues  in  the  GOM.  The  gom-var-type  attribute  models  the 
data  type  of  the  variable.  Section  4.20  describes  and  lists  the  data  types  modeled  in  the 
GOM.  If  a  variable  is  an  array  with  indices,  the  gom-indices  attribute  is  used  to  model 
the  access  into  the  array. 
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f  (gom-variable)  \ 

gom-name :  PDIAM 
gom-var-scope :  PRDIV 
gom-var-type ;  gom-real 
gom-indices :  [  ] _ y 

Figure  75  GOM  Variable  Object  Example 

For  example,  Figure  75  shows  how  the  local  variable  PDIAM,  defined  in  a  method 
PRDIV,  is  represented  in  the  GOM  using  an  instance  of  the  gom-variable  class.  The 
gom-var-scope  attribute  is  set  to  the  symbol  PRDIV  to  indicate  this  variable  is  in  the  scope 
of  the  method  PRDIV.  The  data  type  of  PRDIV  is  modeled  using  the  gom-real  object.  The 
gom-indices  attribute  holds  an  empty  sequence  to  indicate  this  variable  has  no  indices. 

4.19  Attributes 

In  the  object  paradigm,  data  items  are  also  stored  as  attributes  of  objects.  As  de¬ 
scribed  in  Section  4.4,  classes  define  a  template  for  objects  by  declaring  attributes  that  are 
built  into  each  instance  of  the  class.  This  forms  a  collection  of  variables  associated  with 
the  object  that  are  accessed  as  attributes  of  the  object.  This  section  defines  the  AST  class 
that  models  object  attributes  in  the  GOM  and  presents  an  example  of  how  an  attribute  is 
modeled. 

Attributes  are  modeled  in  the  GOM  using  the  gom-attribute  class.  Figure  76  shows 

gom-attribute 

gom-name :  symbol 
gom-var-scope :  symbol 
gom-var-type :  gom-data-type 
gom-indices :  seq(gom-data-constract) 

Figure  76  GOM  Attribute  Class 

the  class  definition  for  the  gom-attribute  class.  The  gom-name  attribute  holds  a  symbol 
that  represents  the  name  of  the  attribute.  The  gom-var-scope  attribute  holds  a  symbol 
that  represents  the  scope  of  this  attribute.  The  gom-var-type  attribute  models  the  data 
type  of  the  attribute.  If  an  attribute  is  an  array,  the  gom-indices  attribute  is  used  to  model 
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the  indices  used  when  accessing  the  array.  Note  that  the  classes  that  model  variables  and 
attributes  in  the  GOM  are  identical.  This  is  because  of  the  similarity  between  attributes 
and  variables  in  the  00  paradigm. 


class  CLASS-2  attributes  ZCOS 
method  GET-ZCOS  (  C-10  ) :  real 
begin 

GET-ZCOS  :=  C-10. ZCOS 
end 

method  SET-ZCOS  (  C-11,  VAL-10  ) 
begin 

C-11. ZCOS  :=  VAL-10 
end 

superclass  USER-OBJECT 


Figure  77  Example  of  ZCOS  Attribute 


For  example,  consider  the  class  shown  in  Figure  77.  The  CLASS-2  class  has  one  at¬ 
tribute,  ZCOS.  The  “SET-”  and  “GET-”  methods  are  also  shown  in  the  figure.  As  described 
in  Section  4.4,  the  gom-attrs  attribute  of  the  class  gom-class  models  the  attributes  of 
a  class.  These  attributes  are  modeled  using  instances  of  the  gom-attribute  class.  For 


(gom-attribute) 
gom-name :  ZCOS 
gom-var-scope ;  CLASS-2 
gom-var-type :  gom-real 
gom-indices :  [  ] 


Figure  78  GOM  Attribute  Object  Example 


example.  Figure  78  shows  the  gom-attribute  object  that  models  the  ZCOS  attribute  of 
the  CLASS-2  class.  The  gom-name  attribute  holds  the  symbol  ZCOS.  The  gom-var-scope 
attribute  holds  the  symbol  CLASS-2  to  represent  the  fact  that  ZCOS  is  declared  in  the  scope 
of  CLASS-2.  The  gom-var-type  attribute  models  the  data  type  of  the  attribute,  which  in 
this  example  is  real. 
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4-20  Data  types 

This  section  describes  the  data  types  that  are  used  when  modeling  variables  in  the 
GOM.  The  data  types  being  modeled  are  as  follows. 

Instance  object  instances  of  a  class 

Integer  zero  and  positive  and  negative  whole  numbers 

Real  rationals  and  irrationals 

Boolean  true  and  false  logical  values 

Character  single  alpha  characters 

String  sequences  of  characters 

Array  homogeneous  collections  of  elements  accessed  with  an  index. 

The  Instance  data  type  is  used  as  the  data  type  of  variables  in  the  GOM  that  are 
instances  of  a  class.  Each  of  the  data  types  presented  here  is  modeled  using  a  separate  class 
in  the  GOM.  In  order  to  model  a  specific  data  type  in  the  GOM,  the  data  type  attribute  of 
GOM  variables  and  GOM  attributes  holds  an  instance  of  an  AST  built  from  the  class  that 
models  the  data  type  of  the  variable  or  attribute.  Examples  of  this  are  shown  in  Figure  75 
and  Figure  78. 

As  discussed  in  Section  3.15,  the  number  of  bytes  associated  with  an  imperative  data 
type  can  be  specified  by  the  user  or  derived  from  pre-defined  data  types.  This  is  true  in 
the  object  paradigm  as  well,  so  each  class  that  models  an  object-oriented  data  type  has  an 
attribute  gom-type-size  that  models  the  number  of  bytes  associated  with  the  data  type. 

4-21  Scoping  Issues 

As  in  the  imperative  paradigm,  each  variable  in  the  object-oriented  paradigm  has  a 
scope  associated  with  it  that  refers  to  its  “visibility”.  A  method  that  defines  a  variable 
has  visibility  to  the  variable.  A  variable  that  is  an  instance  of  a  class  provides  visibility  to 
the  attributes  of  the  instance.  Attributes  in  the  object-oriented  paradigm  also  have  scope. 
This  section  describes  how  the  scope  of  variables  and  attributes  in  the  GOM  is  modeled. 

In  the  GOM,  each  method  has  a  local  scope  much  as  subprograms  in  the  GIM  have 
a  local  scope.  If  a  variable  is  declared  in  a  method,  this  local  variable  is  only  visible  to  the 
declaring  method.  The  formal  parameters  of  a  method  are  also  only  visible  to  the  declaring 
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method.  In  order  for  statements  in  a  method  to  access  the  attributes  of  an  instance,  the 
instance  must  be  a  local  variable  or  a  formal  parameter  of  the  method. 

Some  object-oriented  programming  languages  allow  variables  declared  outside  the 
local  scope  to  be  accessed  by  a  method.  This  type  of  access  is  not  allowed  in  the  GOM, 
which  leads  to  the  following  restriction. 

Restriction  IV.8.  All  variables  in  a  GOM  method  are  either  declared  locally  or  are  formal 
parameters  of  the  method. 

In  the  object  paradigm,  a  method  passes  information  to  other  methods  by  including 
variables  as  parameters  of  messages.  As  in  the  imperative  paradigm,  parameters  are  either 
input  or  output,  i.e.  the  value  of  the  parameter  is  either  read  in  the  method  or  written  to 
in  the  method.  If  one  method  passes  a  variable  to  another  method  as  an  output  parameter, 
the  method  being  called  changes  the  value  of  the  variable  in  the  calling  method.  As  in 
the  imperative  paradigm,  this  is  termed  pass  by  reference  parameter  passing  [16].  All 
parameters  are  passed  by  reference  in  the  GOM. 

In  some  object-oriented  programming  languages,  one  method  can  be  declared  inside 
another  method.  This  means  the  method  would  be  visible  only  to  the  method  in  which  it 
was  declared.  Limiting  the  visibility  of  a  method  in  this  way  is  not  allowed  in  the  GOM, 
which  leads  to  the  following  restriction. 

Restriction  IV.9.  Methods  cannot  be  declared  inside  of  another  method. 

Each  of  the  methods  declared  in  the  GOM  must  be  part  of  a  class,  i.e.  in  the  set  of 
operations  for  a  class.  This  means  a  particular  class  has  visibility  to  each  of  the  methods 
declared  within  it.  When  a  message  is  sent  to  a  target  object,  the  class  of  the  object  is  used 
to  determine  with  method  to  invoke.  This  mechanism  is  represented  and  canonicalized  in 
the  GOM  by  requiring  each  class  to  be  declared  in  one  overall  global  scope.  This  leads  to 
the  following  restriction  on  the  GOM. 

Restriction  IV.IO.  Classes  cannot  be  declared  inside  of  another  class. 
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4-22  Homogeneous  Data  Structures 

As  in  the  imperative  paradigm,  collections  of  homogeneous  elements  can  be  built  in 
the  object  paradigm  using  constructs  such  as  lists  and  arrays.  The  only  such  collection 
modeled  in  the  GOM  is  the  array.  Arrays  are  represented  in  the  GOM  by  building  variables 
and  attributes  of  the  data  type  gom-array  (see  Section  4.20). 

For  example,  the  following  statement  includes  an  access  to  the  array  variable  GEOM. 

RANGE  :=  RANGE  +  GEOM  (  K) 

The  GOM  AST  shown  in  Figure  79  models  this  access  to  the  Kth  element  of  the  GEOM  array 
variable. 


Figure  79  GEOM  Array  Variable  Access  Object 

If  an  attribute  of  an  object  is  an  array,  then  the  indices  used  to  access  the  array 
are  passed  as  parameters  to  the  “GET-”  or  “SET-”  message  that  accesses  the  attribute. 
For  example,  the  following  statement  accesses  the  Kth  element  of  the  GEOM  attribute  of  the 
instance  variable  C-10. 

RANGE  :=  RANGE  +  GET-GEOM  (  C-10,  K) 

The  GEOM  attribute  is  an  array  and  the  GET-GEOM  message  is  used  to  access  the  elements 
of  the  array.  In  the  statement,  the  message  GET-GEOM  (  C-10,  K)  is  sent  to  the  target 
object  C-10  requesting  element  K  from  the  GEOM  array  attribute.  The  GOM  AST  shown  in 
Figure  80  models  the  message  used  to  access  the  Kth  element  of  the  GEOM  array  attribute. 
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(gom-message) 
gom-call :  GET-GEOM 


gom-actuals 


(gom-variable) 
gom-name  =  C-10 
gom-var-scope  =  PRDIV 
gom-indices  =  [  ] 
gom-var-type  =  CLASS- 10 

(gom-variable) 

gom-name  =  K 
gom-var-scope  =  PRDIV 
gom-indices  =  [  ] 
gom-var-type  =  gom-integer 


Figure  80  GEOM  Attribute  Array  Access  Object 

The  first  parameter  of  the  message  is  the  target  object  C-10  and  the  second  parameter  is 
the  variable  K.  This  variable  holds  the  index  of  the  element  to  be  retrieved  from  the  array. 

To  set  the  value  of  an  array  attribute,  the  appropriate  “SET-”  message  is  used.  For 
example,  the  following  statement  sets  the  Kth  element  of  the  GEOM  attribute  to  the  value 
of  the  RANGE  variable. 

SET-GEOM  (  C-10,  K,  RANGE) 

In  this  statement,  the  message  SET-GEOM  (  C-10,  K,  RANGE)  is  sent  to  the  target 
object  C-10  in  order  to  set  the  Kth  element  to  the  value  of  the  RANGE  variable.  The  GOM 
AST  shown  in  Figure  81  models  the  “SET-”  message.  The  first  parameter  is  the  target 
object  C-10,  the  second  parameter  is  the  index  variable  K,  and  the  final  parameter  is  the 
variable  to  which  the  array  element  will  be  set,  i.e.  the  RANGE  variable. 

Figure  82  shows  the  GET-GEOM  and  SET-GEOM  methods  used  for  accessing  and  assign¬ 
ing  a  value  to  the  GEOM  array  attribute. 
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(gom-message) 
gom-call :  SET-GEOM 


gom-actuals 


(gom-variable) 

gom-name  =  C-10 
gom-var-scope  =  PRDIV 
gom-indices  =  [  ] 
gom-var-type  =  CLASS- 10 

(gom-variable) 

gom-name  =  K 
gom-var-scope  =  PRDIV 
gom-indices  =  [  ] 
gom-var-type  =  gom-integer 

(gom-variable) 
gom-name  =  RANGE 
gom-var-scope  =  PRDIV 
gom-indices  =  [  ] 
gom-var-type  =  gom-integer 


Figure  81  GEOM  Attribute  Array  Access  Object 
4.-23  Heterogeneous  Data  Structures 

Some  object-oriented  programming  languages  allow  the  programmer  to  build  collec¬ 
tions  of  heterogeneous  data  items,  for  example,  records  in  Ada  95  and  structs  in  C-t--!-. 
These  heterogeneous  data  structures  are  not  modeled  in  the  GOM. 

Restriction  IV.ll.  The  GOM  does  not  model  heterogeneous  data  structures. 


4.24  Pointers 

As  in  the  imperative  paradigm,  some  object-oriented  programming  languages  allow 
the  programmer  to  store  the  address  of  a  variable  and  then  access  the  variable  via  the 
address.  This  mechanism  is  referred  to  as  using  pointers  to  variables.  Pointers  are  not 
modeled  in  the  GOM. 

Restriction  IV. 12.  The  GOM  does  not  model  pointers. 
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method  GET-GEOM  (  C-10,  IDX-1  ):  real 
begin 

GET-GEOM  :=  C-IO.GEOM  (  IDX-1) 
end 

method  SET-GEOM  (  C-11,  IDX-2,  VAL-10  ) 
begin 

C-ll.GEOM  (  IDX-2)  :=  VAL-10 
end 

Figure  82  “SET-”  and  “GET-”  Methods  for  GEOM 
4-25  Object-Oriented  Expressions 

In  the  object-oriented  paradigm,  expressions  can  be  literal  values,  unary  or  binary  ex¬ 
pressions  with  operators,  non-user-defined  function  calls,  functional  messages,  or  variables. 
This  section  describes  how  expressions  are  modeled  in  the  GOM. 

Literal  values  in  the  GOM  are  modeled  by  the  gom-literal-constant  class.  The 

gom-literal-constant 
gom-literal-value :  any-type 


Figure  83  Modeling  Object-Oriented  Literal  Constants 

class  description  for  the  gom-literal-constant  cla.ss  is  shown  in  Figure  83.  The  gom- 
literal-value  attribute  models  the  value  of  the  literal.  Figure  84  shows  the  literal  con- 

gom-literal-integer 

gom-literal-real 

gom-literal-boolean 

gom-literal-string 

Figure  84  Object-Oriented  Literal  Constants 

stants  currently  modeled  in  the  GOM.  Each  literal  shown  is  modeled  as  an  AST  defined 
as  a  subclass  of  the  gom-literal-constant  class.  As  in  the  GIM,  literal  constants  other 
than  those  listed  in  Figure  84  are  not  modeled  in  the  GOM,  but  can  be  modeled  by  defin¬ 
ing  a  new  subclass  under  the  gom-literal-constant  class  that  describes  the  new  literal 
constant. 
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Unary  expressions  in  the  GOM  are  modeled  using  ASTs  built  from  the  gom-imary- 
expression  class.  Figure  85  shows  the  class  description  for  the  gom-imary-expression 

gom-unary-expression 
gom-unary-operand :  gom-expression 

Figure  85  Modeling  Object-Oriented  Unary  Expressions 

class.  The  gom-unary-operand  attribute  models  the  single  operand  of  the  unary  expres¬ 
sion.  Figure  86  shows  all  the  unary  expressions  modeled  in  the  GOM.  Each  unary  ex- 

gom-negate 

gom-not 

Figure  86  List  of  Object-Oriented  Unary  Expressions 

pression  shown  is  modeled  as  an  AST  defined  as  a  subclass  of  the  gom-unary-expression 
class.  As  with  literal  constants,  any  unary  expressions  other  than  those  listed  in  Figure  86 
are  not  modeled  in  the  GOM  but  can  be  built  as  a  new  subclass  that  defines  the  new  unary 
expression. 

Binary  expressions  in  the  GOM  are  modeled  by  the  gom-binary-expression  class. 
Figure  87  shows  the  class  description  for  gom-binary-expression  class.  As  in  the  impera- 

gom-binary-expression 

gom-bin-exp-operand-l  :  gom-expression 
gom-bin-exp-operand-2 :  gom-expression 
gom-bin-exp-seq :  seq(gom-expression) 

Figure  87  GOM  Binary  Expressions  Class 

tive  paradigm,  binary  expressions  in  the  object-oriented  paradigm  have  either  two  operands 
or  multiple  operands.  For  this  reason,  the  gom-binary-expression  class  has  three  at¬ 
tributes  for  modeling  the  operands  of  the  expression.  The  gom-bin-exp-operand-l  and 
gom-bin-exp-operand-2  attributes  hold  the  two  operands  if  the  binary  expression  has 
only  two  operands.  When  the  same  binary  expression  is  repeated  for  multiple  operands, 
such  as  in  the  expression  ZCOS  *  ZCOS  *  ZCOS,  the  multiple  operands  are  modeled  using 
the  gom-bin-exp-seq  attribute.  Certain  binary  expressions  can  be  repeated  in  this  way. 
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e.g.  addition  and  multiplication.  Others  cannot  be  repeated  in  this  way,  e.g.  <,  <=,  and 


>. 


gom-division 

gom-equal 

gom-exponent 

gom-greater-than-or-equal 

gom-greater-than 

gom-less-than-or-equal 

gom-less-than 

gom-not-equal 

gom-subtraction 


gom-addition 

gom-and 

gom-concat 

gom-multiplication 

gom-or 


(a)  Two  operand. 


(b)  Sequence. 


Figure  88  Object-Oriented  Binary  Expressions  Modeled  in  the  GOM 

Figure  88  lists  all  the  binary  expressions  that  are  modeled  in  the  GOM.  The  binary 
expressions  that  cannot  be  repeated  are  shown  in  Figure  4.88(a).  These  expressions  are 
modeled  using  the  gom-bin-exp-operand-1  and  gom-bin-exp-operand-2  attributes.  The 
binary  expressions  that  can  be  repeated  are  shown  in  Figure  4.88(b).  These  expressions 
are  modeled  using  the  gom-bin-exp-seq  attribute. 

As  with  literal  constants  and  unary  expressions,  any  binary  expressions  not  shown 
in  Figure  88  are  not  modeled  in  the  GOM.  New  binary  expressions  are  modeled  by  adding 
a  subclass  to  the  gom-binary-expression  class  to  define  the  new  binary  expression. 


4-26  Object-Oriented  Input 

This  section  defines  the  ASTs  that  are  used  to  model  input  statement  from  object- 
oriented  programming  languages.  Most  object-oriented  programming  languages  allow  the 
programmer  to  input  data  items  from  a  file  or  the  console.  The  GOM  models  this  aspect 
of  object-oriented  programming  languages  using  ASTs  as  defined  below. 

Input  statements  are  modeled  in  the  GOM  by  using  ASTs  built  from  the  gom-input 
class.  Figure  89  shows  the  class  description  for  the  gom-input  class.  The  gom-in-logical- 
f  ile  attribute  is  used  to  model  the  source  of  the  input.  In  the  GOM,  input  coming  from 
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gom-input 

gom-in-logical-file :  gom-data-construct 
gom-input-list :  seq(gom-format-item) 

Figure  89  GOM  Input  Class 

the  user  is  modeled  by  setting  this  attribute  to  the  symbol  CONSOLE.  The  gom-input-list 
attribute  models  the  sequence  of  items  being  input. 

For  example,  the  following  input  statement  (shown  in  GOL  syntax) 
read  (  CONSOLE,  NLASER) 

inputs  the  value  of  the  variable  NLASER  from  the  console,  which  is  indicated  by  the  symbol 
CONSOLE  as  the  first  parameter  of  the  statement.  Figure  90  shows  how  this  input  statement 


Figure  90  GOM  Input  Object 


is  modeled  using  an  AST  in  the  GOM.  The  gom-in-logical-file  attribute  holds  the 
symbol  CONSOLE  to  indicate  the  input  is  coming  from  the  user.  The  gom-input-list 
attribute  is  a  singleton  list  holding  the  NLASER  variable. 

As  in  the  imperative  paradigm,  object-oriented  programming  languages  also  allow 
the  programmer  to  input  data  from  a  file.  Before  inputting  data  from  the  file,  the  file 
must  be  “opened”  to  establish  the  logical  link  to  the  physical  file  on  disk.  These  files  are 
modeled  in  the  GOM  using  ASTs  built  from  the  gom-f  ile  class.  Figure  91  shows  the  class 
description  for  the  gom-f  ile  class.  The  gom-designator  attribute  holds  the  name  of  the 
logical  file  as  referenced  in  the  program.  The  gom-f  ile-name  attribute  holds  the  name  of 
the  physical  file.  The  gom-access  attribute  holds  the  access  type  for  the  file,  e.g.  direct  or 
sequential.  The  gom-status  attribute  holds  the  status  of  the  file,  opened  either  for  input 
or  output.  ASTs  built  to  model  files  are  stored  as  attributes  of  a  design  in  the  GOM. 
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gom-file 

gom-designator ;  gom-data-construct 
gom-file-name :  gom-data-construct 
gom-access :  symbol 
gom-status :  symbol 

Figure  91  GOM  File  Class 

The  semantics  of  the  GOM  input  statement  are  similar  to  the  semantics  of  the  GOM 
assignment  statement.  Both  statements  define  values  for  variables.  In  general,  an  input 
statement  in  the  GOM  is  equivalent  to  a  subprogram  call  where  all  the  parameters  are 
output  from  the  subprogram. 

For  example,  let  I  represent  an  input  statement  and  let  a  represent  a  vector  of 
variables  in  the  gom-input-list  attribute  of  I  (as  modeled  in  the  GOM).  Let  x  represent 
a  vector  of  variables  returned  from  the  execution  of  the  input  statement  after  the  values 
are  read  from  the  indicated  file  (or  the  console).  Execution  of  the  GOM  input  statement 
is  equivalent  to  the  following  sequence: 

[7(d),  d  :=  x] 

The  formal  semantics  for  the  GOM  input  statement  J(d)  are  defined  as  follows. 

Definition  IV.12.  wp{I{a),  R)  =  u;p([/(d),  d  :=  x],  R) 

This  indicates  each  of  the  variables  in  the  vector  d  is  set  to  the  values  returned  by 
the  input  statement  7(d). 

4-27  Object-Oriented  Output 

This  section  defines  the  ASTs  that  are  used  to  model  output  statements  from  object- 
oriented  programming  languages.  Most  object-oriented  programming  languages  allow  the 
programmer  to  output  data  items  to  a  file  or  to  the  console.  The  GOM  models  this  aspect 
of  object-oriented  languages  as  defined  below. 

Output  statements  in  the  GOM  using  ASTs  built  from  the  gom-output  class.  The 
class  description  for  the  gom-output  class  is  shown  in  Figure  92.  The  gom-out-logical- 
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gom-output 

gom-out-logical-file :  gom-data-construct 
gom-output-list :  seq(gom-format-item) 

Figure  92  GOM  Output  Class 

file  attribute  represents  whether  the  output  is  being  sent  to  the  console  or  to  an  output 
file.  In  the  GOM,  the  symbol  STD-OUT  is  stored  in  this  attribute  if  the  output  is  going 
to  the  console.  The  gom-output-list  models  the  sequence  of  data  items  that  are  being 
output. 

For  example,  the  following  output  statement  (shown  in  GOL  syntax) 

write  (  STD-OUT,  "  NLASER  =",  NLASER) ; 

outputs  two  data  items  to  the  console.  The  string  literal  "  NLASER  ="  is  output  followed 
by  the  value  of  the  variable  NLASER.  Figure  93  shows  the  AST  used  to  model  this  output 


Figure  93  GOM  Output  Object 


statement  in  the  GOM.  The  gom-out-logical-file  attribute  holds  the  symbol  STD-OUT 
to  indicate  the  output  is  being  sent  to  the  standard  output  port.  The  gom-output-list 
attribute  holds  the  sequence  of  two  data  items  representing  the  string  literal  "NLASER  =" 
and  the  variable  NLASER. 

In  the  GOM,  an  output  statement  is  not  allowed  to  change  the  state  of  the  program. 
Let  O  represent  a  GOM  output  statement  and  let  a  represent  a  vector  of  data  items 
appearing  in  the  output  statement  O.  The  semantics  of  GOM  output  statements  is  defined 
as  follows. 
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Definition  IV.13.  wp(0{a),  R)  =  R 

This  means  the  GOM  output  statements  are  restricted  from  changing  the  state  of 
the  program. 

The  following  sections  provide  formal  definitions  for  object-oriented  classes,  methods, 
messages,  and  designs.  Formal  transformations  of  an  object-oriented  design  are  provided 
at  the  end  of  this  section. 

4-28  Formalizing  GOM  Statements  and  Expressions 

This  section  presents  formal  representations  of  GOM  statements  and  expressions.  Let 
X  represent  a  GOM  variable  and  let  e  represent  a  GOM  expression.  A  GOM  assignment 
statement  is  represented  formally  by  the  following  tuple. 

<  X,  :=,  e  > 

This  tuple  indicates  that  x  is  the  variable  to  be  assigned  the  value  of  the  expression  e.  The 
:  =  symbol  is  a  syntactic  token  that  distinguishes  this  tuple  as  an  assignment  statement. 

Let  e  represent  a  GOM  expression  and  let  Si  and  S2  represent  sequences  of  GOM 
statements.  A  GOM  selection  statement  is  represented  formally  by  the  following  tuple. 

<  if,  e,  then,  5i,  else,  ^2  > 

This  tuple  indicates  that  the  sequence  of  statements  Si  will  be  executed  if  the  expression 
e  evaluates  to  true  otherwise  the  S2  sequence  will  be  executed.  The  if,  then,  and  else 
symbols  are  syntactic  tokens  used  to  identify  this  tuple. 

Similarly,  let  e  represent  a  GOM  expression  and  let  S3  represent  a  sequence  of  GOM 
statements.  The  GOM  iteration  statement  is  represented  by  the  following  tuple 

<  while,  e,  S3  > 
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This  indicates  that  the  sequence  of  statements  53  will  be  executed  while  the  expression  e 
is  true.  The  while  symbol  is  a  syntactic  token  used  to  identify  this  tuple. 

Let  E  represent  a  sequence  of  expressions.  The  GOM  input  and  output  statements 
are  represented  formally  by  the  following  tuples. 

<  input,  iport,  E  > 

<  output,  oport,  E  > 

These  tuples  indicate  that  the  expressions  in  the  sequence  E  are  either  input  from  the 
input  port  iport  or  output  to  the  output  port  oport. 

Expressions  in  the  GOM  are  represented  formally  by  the  following  tuples.  Let  ei  and 
62  be  GOM  expressions. 

<  ei,+,e2  > 

<  ei,  and,  62  > 

<  61,  concat,62  > 

<  ei,  /,62  > 

<  ei,=,62  > 

<ei,  **,62  > 

<  ei,>=,62  > 

<  ei,>,62  > 

<  ei,<=,62  > 

<  ei,<,62  > 

<  ei,*,e2  > 

<  61,0,62  > 

<  61,  or,  62  > 

<  ei,-,62  > 

<  -,ei  > 

<  not,  61  > 

These  formal  representations  are  used  in  the  formal  transformations  presented  in  Chap¬ 
ter  VI. 
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4-29  Formalizing  Object-Oriented  Classes 

This  section  describes  how  classes  modeled  by  the  gom-class  AST  can  be  defined 
more  mathematically.  The  formal  definition  of  an  object-oriented  class  is  presented  below. 


idc  -  A  symbol  storing  the  name  of  the  class. 

$  -  The  set  of  instance  attributes, 
fi  -  The  set  of  instance  methods. 

A  -  The  symbol  storing  the  name  of  the  superclass. 

Thus,  an  object-oriented  class,  C,  is  defined  formally  as 

C  =  <  idc,$c,^C,^  > 


class  CLASS-2  attributes  ZCOS,  XLAMDA,  SIGTRB 
method  GET-ZCOS  (  C-10  ):  real  begin  GET-ZCOS  :=  C-IO.ZCOS 
end 

method  SET-ZCOS  (  C-11,  VAL-10  )  begin  C-ll.ZCOS  :=  VAL-10 
end 

method  GET-XLAMDA  (  C-10  ) :  real  begin 
GET-XLAMDA  :=  C-10. XLAMDA  end 
method  SET-XLAMDA  (  C-11,  VAL-11  )  begin 
C-11. XLAMDA  :=  VAL-11  end 
method  GET-SIGTRB  (  C-10  ) :  real  begin 
GET-SIGTRB  :=  C-10. SIGTRB  end 
method  SET-SIGTRB  (  C-11,  VAL-12  )  begin 
C-11. SIGTRB  :=  VAL-12  end 
superclass  USER-OBJECT 


Figure  94  Class  CLASS  -  2 

For  example.  Figure  94  shows  a  class  (using  GOL  syntax)  that  has  three  attributes 
ZCOS,  XLAMDA,  and  SIGTRB.  The  class  inherits  from  the  class  USER-OBJECT  and  includes 
the  appropriate  methods  to  set  and  access  its  attributes.  This  class  is  formally  defined  by 
the  following  tuple. 
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C  =<  CLASS-2,  USER-OBJECT  >  where 

=  {ZCOS,  XLAMDA,  SIGTRB}  and 
nc  =  {SET-ZCOS,  SET-XLAMDA,  SET-SIGTRB, 

GET-ZCOS,  GET-XLAMDA,  GET-SIGTRB  } 

The  name  of  the  class  is  the  symbol  CLASS-2.  The  attributes  of  the  class  are  repre¬ 
sented  by  the  set  of  data  items  ZCOS,  XLAMDA,  and  SIGTRB.  The  operations  of  the  class 
are  represented  by  the  set  of  methods  including  SET-ZCOS,  SET-XLAMDA,  SET-SIGTRB, 
GET-ZCOS,  GET-XLAMDA,  GET-SIGTRB.  Each  operation  is  represented  by  a  formal  definition 
as  presented  in  the  following  section. 

4.30  Formalizing  Object-Oriented  Methods 

This  section  explains  how  methods  represented  using  gom-method  ASTs  can  be  de¬ 
fined  more  mathematically.  Methods  are  defined  as  follows. 

idM  -  A  symbol  storing  the  name  of  the  method, 
r  -  The  target  object. 

Qobj  ■  The  sequence  of  objects  passed  to  the  method  (other  than  r). 

Q form  ~  The  sequence  of  formal  parameters. 

Qret  -  The  sequence  of  returned  values. 

Qloc  -  The  sequence  of  local  variables. 

-  The  sequence  of  object-oriented  statements. 

Thus,  an  object-oriented  method  is  defined  by  the  tuple; 

<  id^ ,  T ,  Qobj » Qf  OTm->  Qreti  Qloct  > 

All  object-oriented  methods  are  elements  of  ?t  of  some  object-oriented  class. 

For  example.  Figure  95  shows  the  method  UPLREQ.  This  method  expects  an  instance 
of  the  class  CLASS-2  to  be  passed  in  as  the  target  object.  The  method  returns  a  value  of 
type  real.  This  method  is  defined  formally  using  the  following  tuple. 
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class  CLASS-2  attributes  ZCOS,  XLAMDA,  SIGTRB 
method  UPLREQ  (  C-12  ) :  real 
begin 

SIGTO  ;=  3.75d-6; 

TMPl  := 

GET-XLAMDA  (  C-12)  *  GET-ZCOS  (  C-12)  *  GET-ZCOS  (  C-12) 
*  GET-ZCOS  (  C-12); 

TMP2  :=  TMP1~0.2; 

SIGUP  :=  SIGTO  /  TMP2; 
if  GET-SIGTRB  (  C-12)  >0.0  then 

UPLREQ  :=  SIGUP  /  GET-SIGTRB  (  C-12) 
else 

UPLREQ  :=  1000000. OdO 
endif 
end 

superclass  USER-OBJECT 


Figure  95  Method  UPLREQ 


^  UPLREQ, T, ^  ^  where 
T  =  C-12  and 
Qobj  =  [  ] 

Qform  —  [  ]  a,nd 

Qret  =  [UPLREQ  ]  and 

Qioc  =  [SIGTO,  TMPl,  TMP2,  SIGUP  ]  and 

’F  =  the  statements  between  the  BEGIN  and  the  END 

The  name  of  the  method  is  the  symbol  UPLREQ.  The  data  item  C-12  holds  the  target 
object  passed  to  the  method.  UPLREQ  expects  no  other  objects  or  parameters  to  be  passed 
since  the  Qobj  and  Q form  sequences  are  empty.  The  data  item  returned  from  this  method 
is  represented  by  including  the  name  of  the  method  in  the  Qret  sequence.  The  local 
variables  of  UPLREQ  are  the  data  items  SIGTO,  TMPl,  TMP2,  and  SIGUP.  The  sequence  of 
object-oriented  statements  between  the  BEGIN  and  the  END  of  UPLREQ  comprise 
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4-31  Formalizing  Object-Oriented  Messages 


This  section  explains  how  messages  represented  using  the  gom-message  AST  can  be 
defined  more  mathematically.  Messages  are  defined  formally  below. 

ido  -  a  symbol  that  holds  the  name  of  the  method  to  be  invoked. 

Qact  -  a  sequence  of  variables  that  are  the  actual  parameters  passed  to  the  method. 
Qform  ~  a  sequence  of  variables  that  are  formal  parameters  of  the  method  to  be  invoked. 

Let  Cl  be  a  class  that  has  a  method  oi.  Let  be  a  class  that  has  a  method  02  that 
is  invoked  in  oi .  Then,  the  message  sent  in  method  oi  is  represented  by  the  tuple 


<  ido2 ,  Qact  ^ 


In  the  object-oriented  paradigm,  the  number,  order,  and  type  of  parameters  in  Qact  must 
match  the  number,  order,  and  type  of  the  parameters  in  Qform- 

class  CLASS-5  attributes  PHASE,  ZENITH,  UPLFAC 
method  RELAY-PHASE  (  C-14,  C-22,  PHASE  ) 
begin 

PHASE  ;=  UPLREQ  (  C-22  ) 
end 

superclass  USER-OBJECT 

Figure  96  Class  with  method  RELAY-PHASE 

For  example,  as  shown  in  Figure  96,  the  message  UPLREQ  (  C-22  )  is  being  sent  by 
the  RELAY-PHASE  method.  The  target  object  of  this  message  is  C-22  and  this  instance  is 
being  asked  to  execute  the  method  UPLREQ.  The  object  C-22  is  an  instance  of  the  class 
CLASS-2.  Figure  97  shows  the  class  CLASS-2  and  the  (partially  declared)  method  UPLREQ. 
The  message  UPLREQ  (  C-22  )  is  defined  formally  by  the  tuple 

<  UPLREQ,  [  C-22  ]  > 

Since  this  message  is  invoking  the  UPLREQ  method,  the  UPLREQ  identifier  is  the  first  item 
in  the  tuple.  The  singleton  sequence  containing  C-22  represents  that  this  call  is  passing  in 
a  single  parameter,  which  is  the  target  object  C-22. 


116 


class  CLASS-2  attributes  ZCOS,  XLAMDA,  SIGTRB 
method  UPLREQ  (  C-12  ) :  real 
begin 

end 

superclass  USER-OBJECT 

Figure  97  Class  with  method  UPLREQ 
4-32  Formalizing  the  Object  Model 

Rumbaugh  [62]  defines  an  object  model  in  his  Object  Modeling  Technique  (OMT). 
The  object  model  includes  definitions  for  the  classes,  inheritance,  and  aggregation  as¬ 
sociations  in  an  object-oriented  design.  This  section  provides  a  formal  definition  of  an 
object-oriented  design,  a  discussion  of  the  inheritance  and  aggregation  associations  in  the 
design,  and  formal  transformations  for  the  object  model. 

The  formal  definition  of  an  object-oriented  design  is  given  below.  Let  C*  be  a  set 
of  object-oriented  classes  to  be  included  in  an  object-oriented  design.  An  object-oriented 
design  is  represented  formally  using  the  following  one-tuple. 

OOD  =  C* 

An  object-oriented  design  consists  of  the  set  of  classes  to  be  included  in  the  design.  One 
of  these  classes  in  the  design  is  the  system  class  that  includes  the  main  method,  which  is 
given  the  fiow  of  control  when  execution  begins. 

Inheritance  associations  are  represented  in  a  design  by  references  to  the  superclass 
in  a  class  description,  i.e.  the  A  item  in  the  tuple  representing  a  class.  An  aggregation 
association  exists  between  two  classes  when  object  instances  of  one  class  are  stored  as 
instance  attributes  of  the  other  class. 

Blaha  [7]  discusses  several  primitive  transformations  for  object  models.  The  trans¬ 
formations  defined  to  formalize  the  PBOI  method  include  removing  or  adding  a  class  and 
removing  or  adding  an  attribute.  A  mathematical  description  for  these  transformations  is 
provided  below. 
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Let  r+  be  a  transformation  of  the  object  model  that  adds  a  new  class  to  an  existing 
design  and  returns  a  new  object-oriented  design.  Thus, 

r+(OOD,C)  =  OOL>' where 

OOD'  =  OODu{C} 

Let  Tj"  be  a  transformation  of  the  object  model  that  removes  a  class  and  returns  a 
new  object-oriented  design.  Thus, 

T-{OOD,C)  =  OOD'  where 
OOD'  =  OOD-{C} 

Let  be  a  transformation  of  the  object  model  that  adds  a  new  attribute  to  a 
specific  class  and  returns  a  new  object-oriented  design.  Thus, 

T+(OOD,C,a)  =  OOD'  where 
C  =  <  idc,^Ci^C>^  > 

C'  =  <.  idci  *-*  {®})  ^ 

OOD'  =  T+{T-{OOD,C),C') 

Let  be  a  transformation  of  the  object  model  that  removes  an  attribute  of  a  specific 

class  and  returns  a  new  object-oriented  design.  Thus, 

T-{OOD,C,a)  =  OOD'  where 
C  =  <  idc,^Ci^C,^  >  and 
o'  =  <  idcj^c  ~ 

OOD'  =  T^{T-{OOD,C),C') 

Blaha  [7]  does  not  address  the  addition  or  removal  of  a  method  from  a  class.  These 
additional  transformations  are  introduced  below  for  adding  and  removing  a  method,  o,  of 
a  class,  C. 

Let  T+  be  a  transformation  that  adds  a  new  method  to  a  class  and  returns  a  new 
object-oriented  design.  Thus, 
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T+(00£),C,o)  =  OOD'  where 
C  =  <  idc,  ^Ci  ^ 

C'  =  <  ziic'}  ^C>  U  {o},  A  >  and 
OOD'  =  T+{T-{OOD,C),C') 

Let  r“  be  a  transformation  that  removes  a  method  from  a  class  and  returns  a  new 
object-oriented  design.  Thus, 

T-{OOD,C,o)  =  OOD'  where 
C  =  <  idc,^c,^Cy^  >  o-'^d 
O'  =  <.  idct^Ci^C  ~  >  ^'^d 

OOD'  =  T+iT-(OOD,C),C') 


4-33  Summary 

This  chapter  has  defined  the  Generic  Object-Oriented  Design  Model  (GOM)  which 
models  objects,  classes,  methods,  messages,  assignment,  variables,  expressions,  and  control 
flow  in  object-oriented  programming  languages.  Several  restrictions  have  been  placed  on 
the  GOM.  Some  restrictions  are  intended  to  canonicalize  the  representations  of  object- 
oriented  entities.  Other  restrictions  place  limits  on  which  00  entities  can  possibly  be 
modeled  using  the  GOM. 

Specifically,  Restriction  IV.l  states  that  neither  functional  nor  procedural  methods 
can  have  a  parameter  that  is  both  and  input  and  an  output  parameter.  This  restriction 
is  not  unreasonable  since  any  method  that  does  not  meet  this  restriction  can  be  converted 
using  a  process  similar  to  the  one  presented  in  Appendix  D. 

Similarly,  Restriction  IV. 2  does  not  allow  functional  methods  to  return  more  than  one 
data  item.  Hypothetically,  functional  methods  of  this  type  can  be  converted  to  procedural 
methods  that  return  multiple  values. 

Restriction  IV.3  is  intended  to  canonicalize  the  accessing  and  assigning  of  object 
attributes  and  does  not  limit  which  entities  can  be  model  using  the  GOM. 
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Restrictions  IV.6  and  IV.7  limit  messages  to  non-recursive  invocations.  This  restric¬ 
tion  is  reasonable  because  Knuth  [37]  argues  any  recursive  algorithm  can  be  represented 
using  an  iterative  algorithm. 

Restriction  IV.8  does  not  allow  global  variables  to  appear  in  methods.  This  means 
methods  with  variables  other  than  formal  parameters  or  local  variables  must  first  be  con¬ 
verted  into  the  proper  form.  It  is  hypothetically  possible  to  convert  global  variables  into 
formal  parameters  throughout  the  call  tree  of  an  object-oriented  system,  so  this  restriction 
is  not  unreasonable. 

Restriction  IV.9  does  not  allow  one  method  to  be  declared  inside  another  method. 
The  scoping  issues  involved  in  this  nesting  of  methods  is  more  complicated  than  that  of 
variables,  but  it  is  hypothetically  possible  to  convert  the  nested  methods  into  methods 
declared  at  the  global  level.  Similarly,  Restriction  IV.  10  does  not  allow  one  class  to  be 
declared  inside  another  class.  This  is  a  minor  restriction  since  declaring  classes  inside  of 
other  classes  is  not  a  common  practice  in  object-oriented  programming. 

Restriction  IV.4  requires  that  only  calls  to  non-user-defined  subprograms  are  modeled 
by  subprogram  invocations  in  the  GOM.  This  means  that  the  GOM  represents  a  “pure” 
object-oriented  design  where  no  mixing  of  the  imperative  paradigm  and  the  object-oriented 
paradigm  is  allowed.  This  restriction  presents  a  limitation  if  the  design  to  be  modeled  does 
include  such  a  mixture. 

None  of  the  restrictions  discussed  above  preclude  the  representation  of  object-oriented 
entities  in  the  GOM.  However,  Restriction  IV.ll  states  that  heterogeneous  data  types 
are  not  modeled  in  the  GOM,  Restriction  IV.12  states  that  pointers  are  not  modeled  in 
the  GOM.  These  two  restrictions  limit  the  entities  that  can  be  modeled  by  the  GOM. 
If  the  object-oriented  system  being  modeled  includes  either  heterogeneous  data  types  or 
pointers,  the  system  cannot  be  represented  using  the  GOM.  This  is  not  unreasonable  when 
re-engineering  from  the  GIM,  but  is  a  more  serious  limitation  for  representing  languages 
such  as  C-f- 1-  or  Ada  95. 

As  presented  in  this  chapter,  the  GOM  provides  a  canonical  form  for  modeling  en¬ 
tities  in  the  object  paradigm.  Most  of  the  restrictions  placed  on  the  GOM  are  meant  to 
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canonicalize  and  simplify  the  representation  of  these  entities.  The  GOM  is  used  throughout 
the  following  chapters  to  represent  object-oriented  entities. 
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V.  Identifying  Objects 


5.1  Introduction 

This  chapter  introduces  a  novel  method,  Parameter-Based  Object  Identification 
(PBOI),  for  recovering  objects  from  legacy  imperative  programs.  The  method  is  based 
on  fundamental  axioms  that  relate  programs  written  in  imperative  languages  such  as  C  or 
Cobol  to  objects  and  classes  written  in  object-oriented  languages  such  as  Ada  95  or  C-1— 1-. 
This  chapter  provides  an  informal  introduction  to  the  object  identification  methodology. 
Transformations  that  formalize  the  methodology  are  presented  in  Chapter  VI. 

In  order  to  focus  the  task  of  transforming  imperative  subprograms  to  the  object- 
oriented  paradigm,  a  taxonomy  of  imperative  subprograms  has  been  developed.  This 
chapter  describes  the  taxonomy,  which  classifies  all  imperative  subprograms  into  one  of 
six  categories  and  explains  how  the  object  identification  methodology  is  used  to  convert 
subprograms  in  each  of  the  categories.  Finally,  the  chapter  describes  how  the  process  of 
program  slicing  [76]  is  used  to  focus  the  transformation  task  even  further. 

5.2  Taxonomy  of  Imperative  Subprograms 

This  section  describes  the  taxonomy  of  imperative  subprograms  built  to  focus  the 
task  of  re-engineering  imperative  legacy  code  to  the  object  paradigm.  By  defining  this 
taxonomy,  an  imperative  subprogram  can  be  converted  to  the  object  paradigm  by  deter¬ 
mining  the  classification  of  the  subprogram  and  then  applying  the  formal  transformation 
appropriate  to  that  category  of  subprogram.  The  taxonomy  reduces  the  re-engineering 
task  to  defining  the  transformations  for  the  six  categories  of  subprograms  identified.  The 
following  definitions  are  used  to  build  the  taxonomy. 

Definition  V.l.  One  subprogram  calls  another  subprogram  by  using  the  name  of  the  sub¬ 
program  to  invoke  the  other  subprogram. 

Definition  V.2.  Cguh  is  the  collection  of  calls  a  subprogram  makes  to  other  subprograms. 

Definition  V.3.  An  imperative  procedure  produces  a  data  item  if  the  data  item  is  an 
output  parameter. 
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Definition  V.4.  An  imperative  function  produces  the  data  item  returned  at  the  end  of  its 
execution. 


Definition  V.5.  Ppro  is  the  collection  of  data  items  produced  by  a  subprogram. 

The  taxonomy  of  imperative  subprograms  considers  whether  or  not  a  subprogram 
calls  another  subprogram  and  whether  the  subprogram  produces  zero,  one,  or  multiple 
data  items.  The  distinction  between  producing  zero  or  one  data  item  is  important  for  the 
classification  of  the  main  program,  i.e.  the  subprogram  that  is  given  the  fiow  of  control  as 
the  system  begins  execution.  Figure  98  shows  the  taxonomy  of  imperative  subprograms 
based  on  the  sizes  of  Cgub  and  Ppro- 
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Figure  98  Subprogram  Taxonomy 


Category  0  subprograms  produce  no  data  items  and  call  no  other  subprograms.  These 
subprograms  could  consist  of  output  statements  or  busy/wait  loops.  Category  1  subpro¬ 
grams  produce  no  data  items  but  call  other  subprograms.  These  subprograms  could  be 
driver  programs  or  the  main  program.  Category  2  subprograms  produce  a  single  data  item 
and  call  no  other  subprograms.  Category  3  subprograms  produce  a  single  data  item  and 
call  other  subprograms.  Category  4  subprograms  produce  multiple  data  items  and  call  no 
other  subprograms.  Category  5  subprograms  produce  multiple  data  items  and  call  other 
subprograms. 

Since  any  imperative  subprogram  can  be  classified  into  one  of  these  six  categories,  the 
process  of  transforming  the  subprogram  from  the  GIM  to  the  GOM  is  reduced  to  building 
transformations  for  each  category. 

5.3  Parameter-Based  Object  Identification 

Parameter- Based  Object  Identification  (PBOI)  is  a  novel  method  for  identifying  ob¬ 
jects  in  imperative  legacy  code  based  on  the  data  items  passed  as  parameters  in  imperative 
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subprogram  calls.  The  PBOI  method  provides  a  rationale  for  converting  imperative  sub¬ 
programs  into  classes  and  methods  that  implement  the  subprograms.  The  overall  rationale 
for  the  PBOI  method  is  based  on  the  following  thesis. 

Thesis  V.l.  Object  attributes  manifest  themselves  as  data  items  passed  from  subprogram 
to  subprogram  in  the  imperative  paradigm. 

Object  attributes  are  extracted  from  the  parameters  of  imperative  subprograms  using 
specific  transformations  defined  by  the  PBOI  methodology.  Once  the  attributes  of  an 
object  are  built  into  a  class,  the  behavior  associated  with  the  attributes  is  built  into  the 
class. 

In  this  methodology,  it  is  assumed  that  all  data  items  in  an  imperative  subprogram 
are  either  passed  as  parameters  to  the  subprogram  or  declared  locally  in  the  subprogram. 
In  this  way,  the  main  program  is  the  origin  of  all  data  items  being  passed  to  the  imperative 
subprograms. 

The  PBOI  methodology  starts  the  transformation  process  at  the  main  program.  Be¬ 
fore  the  main  program  is  transformed  each  of  the  subprograms  called  by  the  main  program 
is  transformed  to  the  object-oriented  paradigm.  Similarly,  each  of  the  subprograms  called 
by  a  Category  1,  3,  or  5  subprogram  is  converted  before  the  subprogram  itself  is  converted. 
This  depth-first  style  of  transformation  results  in  incremental  designs  being  merged  together 
at  different  steps  in  the  transformation. 

The  following  sections  define  the  PBOI  method  in  detail  as  it  applies  to  the  six 
categories  of  imperative  subprograms.  The  discussions  of  the  different  categories  are  not 
presented  in  numerical  order,  but  in  an  order  that  more  closely  fits  the  incremental  nature 
of  the  PBOI  method. 

5.4  Converting  Category  2  Subprograms 

As  a  starting  point,  consider  the  conversion  of  Category  2  imperative  subprograms. 
These  subprograms  produce  one  data  item  without  calling  any  other  subprograms,  so  an 
analogous  entity  is  needed  from  the  object  paradigm.  In  his  Object  Modeling  Technique 
(OMT),  Rumbaugh  [62]  distinguishes  between  object-oriented  operations  that  have  side 
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effects  and  those  that  merely  compute  a  functional  value.  He  labels  the  latter  form  of 
operation  queries.  Queries  with  no  arguments  except  the  target  object  are  considered 
derived  attributes  [62]  of  the  object.  Imperative  functions  fit  this  description,  so  the  PBOI 
method  uses  the  following  thesis  to  convert  Category  2  functions  to  the  object-oriented 
paradigm. 

Thesis  V.2.  Category  2  imperative  functions  implement  derived  attribute  queries  of  ob¬ 
jects. 

Category  2  imperative  procedures  have  a  single  output  parameter,  so  the  PBOI 
method  uses  the  following  thesis  to  convert  Category  2  procedures  to  the  object-oriented 
paradigm. 

Thesis  V.3.  Category  2  imperative  procedures  implement  side-effecting  operations  of  ob¬ 
jects. 

Based  on  these  two  theses,  the  PBOI  methodology  converts  each  formal  parameter 
of  a  Category  2  subprogram  into  an  attribute  of  a  class  and  transforms  the  subprogram 
into  a  method  of  the  class. 


real  function  CAPTURE 

(  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC  ) 
begin 

TILTFA  :=  DSTN  (  ANGFAC); 

RMAREA  :=  AXMAJ  *  AXMIN; 

EFAREA  :=  RMAREA  *  TILTFA; 

BMAREA  :=  BEAMRA  *  BEAMRA; 
if  EFAREA  <=  BMAREA  *  6.0d0 
then  USED  :=  EFAREA  /  BMAREA; 

CAPTURE  :=  l.OdO  -  DEXP  (  -USED) 
else  CAPTURE  :=  l.OdO  endif 
end 


Figure  99  Imperative  function  CAPTURE 

For  example,  consider  the  imperative  function  CAPTURE  shown  in  Figure  99.  This 
function  is  shown  using  the  GIL  surface  syntax.  The  CAPTURE  function  is  a  Category  2 
subprogram  that  returns  a  single  value  of  type  real.  The  parameters  BEAMRA,  AXMAJ,  AXMIN, 
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and  ANGFAC  are  passed  into  the  function  and  used  by  the  statements  of  the  function  to 
calculate  the  value  returned.  The  CAPTURE  function  is  converted  to  the  object-oriented 
paradigm  using  the  PBOI  method.  Figure  100  shows  the  class  and  method  built  for 
CAPTURE. 


class  CLASS-2  attributes 

AXMIN,  AXMAJ,  BEAMRA,  ANGFAC 
method  CAPTURE  (  C-2  ) :  real 
begin 

TILTFA  :=  DSTN  (  GET- ANGFAC  (  C-2)); 
RMAREA  :=  GET- AXMAJ  (  C-2) 

*  GET-AXMIN  (  C-2); 

EFAREA  :=  RMAREA  *  TILTFA; 

BMAREA  :=  GET-BEAMRA  (  C-2) 

*  GET-BEAMRA  (  C-2); 

if  EFAREA  <=  BMAREA  *  6.0d0 
then  USED  :=  EFAREA  /  BMAREA; 

CAPTURE  :=  l.OdO  -  DEXP  (  -USED) 
else  CAPTURE  :=  l.OdO  endif 
end 

superclass  USER-OBJECT 


Figure  100  Class  and  method  built  for  CAPTURE 

This  class  and  method  are  represented  in  the  figure  using  the  GOL  surface  syntax. 
Note  that  each  of  the  parameters  BEAMRA,  AXMAJ,  AXMIN,  and  ANGFAC  are  attributes  of 
the  class  CLASS-2.  The  method  that  implements  the  CAPTURE  subprogram  has  been  built 
as  the  single  method  of  CLASS-2.  This  method  expects  one  parameter,  C-2,  which  is  an 
instance  of  CLASS-2,  and  the  method  returns  a  value  of  type  real.  The  statements  of  the 
method  now  access  the  BEAMRA,  AXMAJ,  AXMIN,  and  ANGFAC  data  items  from  the  object  C-2 
in  order  to  calculate  the  value  returned  from  the  method. 

Because  of  Restriction  IV.3,  the  BEAMRA,  AXMAJ,  AXMIN,  and  ANGFAC  attributes  are 
accessed  using  the  “GET-”  and  “SET-”  methods.  Each  “GET-”  and  “SET-”  method  is 
generated  for  each  attribute  and  added  to  the  set  of  operations  for  the  class.  Similarly, 
a  method  to  instantiate  instances  of  the  class  is  needed,  so  a  “CREATE-”  method  is 
generated  for  each  class.  These  methods  are  not  generated  until  the  main  program  is 
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transformed,  which  explains  why  they  do  not  appear  in  Figure  100.  The  transformation 
that  formalizes  the  generation  of  these  methods  is  presented  in  Section  6.11.2. 

The  conversion  of  Category  2  procedures  is  identical  to  the  conversion  of  Category  2 
functions  except  that  the  single  output  parameter  is  converted  to  an  attribute  of  the  new 
class  built  for  the  subprogram.  By  using  this  part  of  the  PBOI  method,  all  Category  2 
subprograms  can  be  converted  to  the  object-oriented  paradigm. 

5.5  Converting  Category  0  Subprograms 

A  Category  0  subprogram  produces  no  data  items  and  calls  no  other  subprograms. 
These  subprograms  may  be  routines  that  include  imperative-output  statements,  or  they 
may  be  needed  in  the  system  for  timing  considerations.  Category  0  subprograms  are 
treated  as  a  special  case  of  Category  2  subprograms.  All  Category  0  subprograms  are 
transformed  to  the  object-oriented  paradigm  by  using  the  transformation  defined  for  Cat¬ 
egory  2  subprograms. 

5.6  Converting  Category  S  Subprograms 

Category  3  subprograms  produce  a  single  data  item  and  call  other  subprograms. 
Since  Category  3  subprograms  call  other  subprograms,  the  attributes  of  objects  that  have 
already  been  built  can  be  analyzed  using  the  PBOI  methodology.  This  section  describes  the 
depth-first  analysis  that  is  done  to  the  object-oriented  design  while  transforming  Category 
3  subprograms  to  the  object-oriented  paradigm. 

The  first  step  in  converting  a  Category  3  subprogram  is  to  transform  all  of  the 
subprograms  that  it  calls.  Then  a  new  class  with  a  method  that  implements  the  Category 
3  subprogram  is  built.  Initially  this  class  has  an  attribute  built  from  each  of  the  parameters 
of  the  subprogram,  as  was  done  for  Category  2  subprograms.  As  Category  3  subprograms 
are  converted  to  the  object-oriented  paradigm,  the  attributes  of  this  class,  as  well  as  the 
attributes  of  the  other  classes  in  the  design,  are  filtered  to  determine  which  should  remain 
attributes  and  which  should  be  converted  from  attributes  to  parameters  of  the  methods. 
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Specifically,  consider  the  case  where  a  Category  3  subprogram  Si  makes  one  call  to 
another  subprogram  S2  {S2  may  be  from  any  category  in  the  taxonomy).  Each  of  the 
actual  parameters  from  5i  in  the  call  to  S2  is  linked  to  a  corresponding  formal  parameter 
in  the  declaration  of  S2.  Let  Ci  represent  the  class  built  for  Si  and  let  C2  represent  the 
class  built  for  S2. 

An  actual  parameter  from  Si  may  or  may  not  also  be  a  formal  parameter  of  Si ,  and 
the  corresponding  formal  parameter  in  S2  may  be  an  attribute  of  C2  or  a  parameter  of  the 
method  in  C2.  Figure  101  shows  the  four  cases  considered  for  each  actual  parameter  when 
converting  a  Category  3  subprogram.  In  each  PBOI  case,  a  specific  change  is  made  to  the 


Actual  is  Formal 

Actual  is  not  Formal 

Formal  is  Attribute 

PBOI  Case  1 

PBOI  Case  3 

Formal  is  Parameter 

PBOI  Case  2 

PBOI  Case  4 

Figure  101  PBOI  Cases 


design  developed  so  far  as  explained  below. 

PBOI  Case  1  The  data  item  remains  an  attribute  of  C2  and  is  removed  as  an  attribute 
of  Cl. 

PBOI  Case  2  The  data  item  is  converted  from  an  attribute  of  Ci  to  a  parameter  of  Ci’s 
method. 

PBOI  Case  3  The  data  item  is  converted  from  an  attribute  of  C2  to  a  parameter  of  C2’s 
method. 

PBOI  Case  No  change  is  required  for  the  design. 

In  Case  1,  the  data  item  has  already  been  made  an  attribute  of  C2,  so  it  should  not 
be  built  as  an  attribute  of  another  class,  i.e.  Ci.  In  Case  2,  it  has  been  determined  through 
some  earlier  filtering  that  the  data  item  should  not  be  an  attribute,  so  it  is  not  built  as  an 
attribute  of  Ci.  In  Case  3,  the  data  item  is  not  being  passed  down  from  the  main  program, 
so  it  is  not  part  of  an  object.  Thus,  it  is  filtered  out  of  C2  and  moved  to  a  parameter.  In 
Case  4,  the  data  item  is  not  being  passed  down  and  it  is  already  a  parameter  instead  of  an 
attribute.  These  four  cases  are  used  to  evaluate  the  entire  design  built  so  far  when  each 
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Category  3  subprogram  is  converted  to  the  object-oriented  paradigm.  For  clarification,  an 
example  is  given  in  the  following  sections  for  each  of  the  PBOI  cases. 

5.6.1  PBOI  Case  1.  As  an  example  of  PBOI  Case  1,  consider  the  Category 
3  subprogram  BOUNCE  shown  in  Figure  102  (using  the  GIL  surface  syntax).  The  BOUNCE 


real  function  BOUNCE  (  ANGFAC,  RNGFAC,  PROJRA, 
SIGB,  RANGE,  AXMAJ,  AXMIN,  XLAMDA) 
begin 

RHOSTD  :=  0.95  *  PROJRA  *  ANGFAC; 

BEAMRA  := 

RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE); 
BOUNCE  := 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 

*  RHO  (  RHOSTD,  XLAMDA,  ANGFAC) 

end 


Figure  102  Subprogram  BOUNCE 

subprogram  calls  the  Category  2  subprogram  RADIUS  shown  in  Figure  103,  as  well  as  the 
CAPTURE  and  RHO  subprograms  (not  shown  in  the  figures).  Figure  104  shows  the  class  built 
for  the  RADIUS  subprogram  (using  the  GOL  surface  syntax)  by  using  the  rule  for  Category 
2  subprograms.  Note  that  the  formal  parameters  of  RADIUS  have  been  built  as  attributes 
of  the  class  CLASS-1. 


real  function  RADIUS 

(  PROJRA,  SIGB,  RNGFAC,  RANGE  ) 
begin 

if  RNGFAC  >  0,0  and  RANGE  >0.0 
then  SIGABS  :=  DABS  (  SIGB); 

SLOPE  :=  SIGABS  -  PROJRA  /  RANGE; 

SPOT  :=  SIGABS  *  RANGE; 

RAD  :=  DABS  (  PROJRA  +  SLOPE  *  RNGFAC); 
RADIUS  :=  DMAXl  (  SPOT,  RAD) 
else 

RADIUS  :=  PROJRA  endif 

end 


Figure  103  Subprogram  RADIUS 
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In  the  call  to  RADIUS,  the  actual  parameters  PRO  JRA,  SIGB,  RNGFAC  and  RANGE  are  also 
formal  parameters  of  the  BOUNCE  subprogram.  These  four  data  items  provide  an  example 


class  CLASS-1  attributes 

RANGE,  RNGFAC,  SIGB,  PRO JRA 
method  RADIUS  (  C-1  ) :  real 
begin 

if  GET-RNGFAC  (  C-1)  >  0.0  and 
GET-RANGE  (  C-1)  >  0.0 
then  SIGABS  :=  DABS  (  GET-SIGB  (  C-1)); 
SLOPE  :=  SIGABS  -  GET-PROJRA  (  C-1) 

/  GET-RANGE  (  C-1); 

SPOT  :=  SIGABS  *  GET-RANGE  (  C-1); 

RAD  :=  DABS  (  GET-PROJRA  (  C-1)  + 
SLOPE  *  GET-RNGFAC  (  C-l)); 

RADIUS  :=  DMAXl  (  SPOT,  RAD) 
else  RADIUS  :=  GET-PROJRA  (  C-1)  endif 
end 

superclass  USER-OBJECT 


Figure  104  Class  and  method  built  for  RADIUS 

of  PBOI  Case  1  and  remain  attributes  of  CLASS-1. 

Figure  105  shows  the  initial  class  and  method  built  for  the  Category  3  subprogram 
BOUNCE.  Note  that  the  subprogram  calls  to  RADIUS,  CAPTURE,  and  RHO  have  not  yet  been 
transformed  to  messages,  i.e.  the  transformation  is  incomplete.  Also  note  that  each  of 
the  parameters  from  the  subprogram  BOUNCE  has  been  built  as  an  attribute  of  the  class 
CLASS-4  including  the  formal  parameters  PROJRA,  SIGB,  RNGFAC  and  RANGE.  Since  these 
data  items  are  passed  to  the  RADIUS  subprogram  and  have  been  built  as  attributes  of  the 
class  built  for  RADIUS,  they  are  examples  of  PBOI  Case  1  and  are  converted  from  attributes 
of  CLASS-4  to  attributes  of  CLASS-1. 

Figure  106  shows  CLASS-4  after  the  attributes  PROJRA,  SIGB,  RNGFAC  and  RANGE  have 
been  converted  from  CLASS-4  to  CLASS-1.  As  shown  in  the  figure,  these  data  items  are 
no  longer  attributes  of  CLASS-4.  The  message  GET-PROJRA  is  now  sent  to  the  object  C-5, 
an  instance  of  CLASS-1,  instead  of  being  sent  to  the  object  C-4,  an  instance  of  CLASS-4. 
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class  CLASS-4  attributes  ANGFAC,  RNGFAC,  PROJRA, 
SIGB,  RANGE,  AXMAJ,  AXMIN,  XLAMDA 
method  BOUNCE  (  C-4  ) :  real 
begin 

RHOSTD  :=  0.95  *  GET-PRO JRA  (  C-4) 

*  GET-ANGFAC  (  C-4); 

BEAMRA  := 

RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE); 
BOUNCE  := 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 

*  RHO  (  RHOSTD,  XLAMDA,  ANGFAC) 

end 

superclass  USER-OBJECT 


Figure  105  Initial  class  built  for  BOUNCE 

The  call  to  the  subprogram  RADIUS  has  been  transformed  into  a  message  sent  to  C-5  that 
invokes  the  RADIUS  method  of  CLASS-i. 

5.6.2  PBOI  Case  2.  As  an  example  of  PBOI  Case  2,  consider  another  version 
of  CLASS- 1  shown  in  Figure  107  that  might  have  been  built  for  the  RADIUS  subprogram. 
The  class  shown  in  the  figure  includes  the  PROJRA  data  item  as  a  parameter  to  the  RADIUS 
method  instead  of  as  an  attribute  of  the  class  CLASS- 1.  This  data  item  provides  an  example 
of  PBOI  Case  2.  Figure  105  shows  the  initial  class  built  for  the  BOUNCE  subprogram.  Each 
of  the  formal  parameters  of  the  subprogram  BOUNCE  has  been  built  as  an  attribute  of 
CLASS-4,  including  the  PROJRA  data  item.  In  this  example,  the  PROJRA  data  item  is  passed 
to  the  RADIUS  subprogram  but  was  not  built  as  a  parameter  of  the  class  built  for  RADIUS. 
This  is  an  example  of  PBOI  Case  2,  so  the  data  item  PROJRA  is  transformed  from  an 
attribute  of  CLASS-4  into  a  parameter  of  the  methods  of  CLASS-4. 

Figure  108  shows  the  updated  class  after  converting  the  data  item  PROJRA  from  an 
attribute  of  CLASS-4  into  a  parameter  of  the  BOUNCE  method.  The  PROJRA  data  item  is 
passed  as  an  actual  parameter  to  the  RADIUS  method.  The  message  GET-PROJRA  (  C-4) 
that  was  used  to  access  PROJRA  as  an  attribute  of  the  class  has  been  converted  to  an  access 
of  the  parameter  PROJRA.  The  class  in  the  figure  has  also  been  updated  to  convert  the  data 
items  SIGB,  RNGFAC  and  RANGE  from  attributes  of  CLASS-4  to  attributes  of  CLASS-1  since 
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class  CLASS-4  attributes 

ANGFAC,  AXMAJ,  AXMIN,  XLAMDA 
method  BOUNCE  (  C-4,  C-5  ):  real 
begin 

RHOSTD  ;=  0.95  *  GET-PRO JRA  (  C-5) 

*  GET-ANGFAC  (  C-4); 

BEAMRA  :=  RADIUS  (  C-5); 

BOUNCE  := 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 

*  RHO  (  RHOSTD,  XLAMDA,  ANGFAC) 

end 

superclass  USER-OBJECT 

Figure  106  Updated  class  built  for  BOUNCE 

these  data  items  are  examples  of  PBOI  Case  1.  The  message  RADIUS  (  C-5,  PRO  JRA) 
now  matches  the  signature  of  the  method  RADIUS  and  is  passed  an  instance  of  CLASS-1 
and  the  parameter  PRO  JRA. 

5.6.3  PBOI  Case  3.  As  an  example  of  PBOI  Case  3,  Figure  109  shows  the 
Category  3  imperative  subprogram  BOUNCE  and  the  Category  2  subprogram  CAPTURE,  which 
is  called  by  BOUNCE.  The  class  originally  built  for  the  CAPTURE  subprogram  is  shown  in 
Figure  110.  Since  CAPTURE  is  a  Category  2  subprogram,  each  of  the  parameters,  including 
the  data  item  BEAMRA,  is  converted  into  an  attribute  of  the  class  CLASS-2.  The  BEAMRA 
data  item  is  not  a  formal  parameter  of  the  subprogram  BOUNCE,  so  it  does  not  remain  an 
attribute  of  CLASS-2.  This  data  item  is  an  example  of  PBOI  Case  3,  so  it  must  be  converted 
from  an  attribute  of  CLASS-2  into  a  parameter  of  the  CAPTURE  method.  Figure  111  shows 
CLASS-2  after  this  change  has  been  made.  Figure  105  shows  the  initial  class  built  for 
the  BOUNCE  subprogram.  The  data  item  BEAMRA  is  not  a  formal  parameter  of  the  BOUNCE 
subprogram,  so  it  has  not  been  built  as  a  parameter  of  the  class  CLASS-4.  There  is  no 
change  required  by  PBOI  Case  3  to  the  attributes  of  CLASS-4  or  the  parameters  of  the 
BOUNCE  method.  The  only  change  made  to  the  statements  of  the  method  is  to  ensure  the 
BEAMRA  data  item  is  passed  as  a  parameter  of  the  CAPTURE  message.  To  illustrate,  note 
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class  CLASS-1  attributes  RANGE,  RNGFAC,  SIGB 
method  RADIUS  (  C-1,  PROJRA  ):  real 
begin 

if  GET-RNGFAC  (  C-1)  >  0.0  and 
GET-RANGE  (  C-1)  >  0,0 
then  SIGABS  :=  DABS  (  GET-SIGB  (  C-1)); 
SLOPE  :=  SIGABS  -  PROJRA 
/  GET-RANGE  (  C-1); 

SPOT  :=  SIGABS  *  GET-RANGE  (  C-1); 

RAD  :=  DABS  (  PROJRA  +  SLOPE  * 
GET-RNGFAC  (  C-1)); 

RADIUS  :=  DMAXl  (  SPOT,  RAD) 
else  RADIUS  :=  PROJRA  endif 
end 

superclass  USER-OBJECT 


Figure  107  Class  built  for  RADIUS 

that  the  AXMAJ,  AXMIN,  and  ANGFAC  data  items  are  examples  of  PBOI  Case  1,  so  they  are 
converted  from  attributes  of  CLASS-4  to  attributes  of  CLASS-2. 

Figure  112  shows  CLASS-4  after  this  transformation  has  been  done  and  the  call 
to  CAPTURE  has  been  converted  into  a  message.  As  shown  in  the  figure,  the  message 
CAPTURE  (  C-6,  BEAMRA)  invokes  the  CAPTURE  method  in  CLASS-2.  The  instance  variable 
C-6  now  includes  the  AXMAJ,  AXMIN,  and  ANGFAC  data  items  as  attributes  (because  of  PBOI 
Case  1),  and  the  BEAMRA  data  item  is  passed  as  an  actual  parameter  of  the  message  (because 
of  PBOI  Case  3). 

5.6.4  PBOI  Case  4-  As  an  example  of  PBOI  Case  4,  consider  the  version  of 
CLASS-2  shown  in  Figure  111.  This  class  has  been  built  for  the  subprogram  CAPTURE  and, 
for  this  example,  the  data  items  AXMAJ,  AXMIN,  and  ANGFAC  have  been  built  as  attributes 
of  the  class.  For  this  example,  the  data  item  BEAMRA  has  been  built  as  a  parameter  of  the 
CAPTURE  method.  As  shown  in  Figure  109,  the  BEAMRA  data  item  is  a  formal  parameter  of 
the  CAPTURE  subprogram. 

Figure  113  shows  the  initial  class  built  for  the  BOUNCE  subprogram,  as  originally 
presented  in  Figure  105.  The  BEAMRA  data  item  is  not  a  formal  parameter  of  the  BOUNCE 
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class  CLASS-4  attributes 

ANGFAC,  AXMAJ,  AXMIN,  XLAMDA 
method  BOUNCE  (  C-4,  C-5,  PROJRA  ):  real 
begin 

RHOSTD  :=  0.95  *  PROJRA 
*  GET-ANGFAC  (  C-4); 

BEAMRA  :=  RADIUS  (  C-5,  PROJRA); 

BOUNCE  ;= 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 

*  RHO  (  RHOSTD,  XLAMDA,  ANGFAC) 

end 

superclass  USER-OBJECT 

Figure  108  Updated  class  built  for  BOUNCE 

subprogram  (as  shown  in  Figure  109).  Since  BEAMRA  is  not  a  formal  parameter  and  it  has 
not  been  built  as  an  attribute  of  CLASS-2,  it  is  an  example  of  PBOI  Case  4.  In  this  case, 
there  are  no  changes  required  to  either  CLASS-2  or  CLASS-4.  The  only  change  made  to 
the  statements  of  the  method  BOUNCE  is  to  ensure  that  BEAMRA  is  included  as  an  actual 
parameter  of  the  CAPTURE  message. 

Figure  114  shows  CLASS-4  after  the  data  items  AXMAJ,  AXMIN,  and  ANGFAC  are  con¬ 
verted  from  attributes  of  CLASS-4  to  attributes  of  CLASS-2  (because  of  PBOI  Case  1)  and 
the  call  to  CAPTURE  has  been  converted  to  a  message.  As  shown  in  the  figure,  the  message 
CAPTURE  (  C-6 ,  BEAMRA)  includes  C-6,  an  instance  of  CLASS-2,  and  the  data  item  BEAMRA 
passed  as  actual  parameters. 

5.6.5  Eliminating  Duplicate  Classes.  In  the  call  tree  of  an  imperative  design,  it 
is  possible  that  one  subprogram  will  have  multiple  calls  to  another  subprogram.  Since  the 
first  step  in  converting  a  Category  3  subprogram  is  to  transform  all  of  the  subprograms 
that  it  calls,  the  subprogram  that  is  called  multiple  times  will  be  converted  multiple  times. 
This  introduces  duplicate  classes  into  the  design  returned  to  the  Category  3  subprogram. 
Furthermore,  there  may  be  different  combinations  of  PBOI  cases  for  each  of  the  calls  to  a 
subprogram.  This  means  the  signature  of  the  method  built  for  one  call  to  a  subprogram 
may  not  match  the  signature  of  the  method  built  for  another  call  to  the  subprogram. 
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real  function  CAPTURE 

(  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC  ) 
begin 

TILTFA  :=  DSIN  (  ANGFAC); 

RMAREA  :=  AXMAJ  *  AXMIN; 

EFAREA  :=  RMAREA  *  TILTFA; 

BMAREA  :=  BEAMRA  *  BEAMRA; 
if  EFAREA  <=  BMAREA  *  6.0d0 
then  USED  :=  EFAREA  /  BMAREA; 

CAPTURE  :=  l.OdO  -  DEXP  (  -USED) 
else  CAPTURE  :=  l.OdO  endif 
end 


real  function  BOUNCE 

(  ANGFAC,  RNGFAC,  PROJRA,  SIGB, 

RANGE,  AXMAJ,  AXMIN,  XLAMDA) 
begin 

RHOSTD  :=  0.95  *  PROJRA  *  ANGFAC; 

BEAMRA  := 

RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE); 
BOUNCE  := 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 
*  RHO  (  RHOSTD,  XLAMDA,  ANGFAC) 

end 


Figure  109  Subprograms  CAPTURE  and  BOUNCE 

To  resolve  this  possible  mismatch  between  the  signature  of  methods  in  duplicate 
classes,  the  duplicate  classes  are  identified  and  eliminated  as  part  of  the  conversion  of 
Category  3  subprograms.  Two  duplicate  classes  are  replaced  in  the  design  with  a  new  class 
that  is  built  as  follows.  The  sets  of  attributes  from  the  two  duplicate  classes  are  compared 
and  any  attributes  not  in  the  intersection  are  moved  from  attributes  to  parameters.  The 
attributes  in  the  intersection  become  attributes  of  the  new  class.  Since  both  duplicate 
classes  include  a  method  that  implements  a  single  subprogram,  the  set  of  operations  for 
the  new  class  includes  the  method  built  for  this  subprogram.  The  resulting  class  replaces 
the  two  duplicate  classes  in  the  design.  If  any  other  methods  include  calls  to  the  methods 
from  the  duplicate  classes,  these  calls  are  updated  to  match  the  signature  of  the  method 
in  the  new  class. 
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class  CLASS-2  attributes 

AXMAJ,  AXMIN,  ANGFAC,  BEAMRA 
method  CAPTURE  (  C-2  ) :  real 
begin 

TILTFA  :=  DSIN  (  GET-ANGFAC  (  C-2)); 
RMAREA  :=  GET-AXMAJ  (  C-2)  * 

GET-AXMIN  (  C-2); 

EFAREA  :=  RMAREA  *  TILTFA; 

BMAREA  :=  GET-BEAMRA  (  C-2)  * 
GET-BEAMRA  (  C-2); 
if  EFAREA  <=  BMAREA  *  6.0d0 
then  USED  :=  EFAREA  /  BMAREA; 

CAPTURE  :=  l.OdO  -  DEXP  (  -USED) 
else  CAPTURE  :=  l.OdO  endif 
end 

superclass  USER-OBJECT 


Figure  110  Original  class  built  for  CAPTURE 

For  example,  Figure  115  shows  two  classes  built  for  the  subprogram  CAPTURE.  The 
signatures  of  the  two  methods  do  not  match  since  BEAMRA  is  passed  as  a  parameter  in  one 
version  and  ANGFAC  is  passed  as  a  parameter  in  the  other.  The  classes  are  easily  identified 
as  duplicates  because  the  names  of  the  two  classes  are  the  same.  These  duplicate  classes 
are  replaced  in  the  design  by  the  class  shown  in  Figure  116.  The  new  version  of  CLASS-2 
includes  attributes  from  the  intersection  of  the  sets  of  attributes  from  the  duplicate  classes. 
The  single  operation  in  the  new  class  is  the  method  from  the  duplicate  classes  updated  to 
properly  access  the  attributes  and  parameters  of  the  new  class. 

Duplicate  classes  may  also  be  introduced  into  the  design  when  different  subprograms 
call  the  same  subprogram.  These  duplicates  will  be  identified  and  eliminated  when  the 
call  subtrees  that  include  the  two  calling  subprograms  join.  This  is  guaranteed  to  happen 
at  least  at  the  main  program. 


5.7  Converting  Category  1  Subprograms 

Category  1  subprograms  produce  no  data  items  but  call  other  subprograms.  These 
subprograms  provide  another  opportunity  to  extract  objects  using  the  PBOI  methodology. 
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class  CLASS-2  attributes  AXMAJ,  AXMIN,  ANGFAC 
method  CAPTURE  (  C-2,  BEAMRA  ):  real 
begin 

TILTFA  :=  DSIN  (  GET- ANGFAC  (  C-2)); 
RMAREA  :=  GET-AXMAJ  (  C-2)  * 

GET-AXMIN  (  C-2); 

EFAREA  :=  RMAREA  *  TILTFA; 

BMAREA  :=  BEAMRA  *  BEAMRA; 
if  EFAREA  <=  BMAREA  *  6.0d0 
then  USED  ;=  EFAREA  /  BMAREA; 

CAPTURE  :=  l.OdO  -  DEXP  (  -USED) 
else  CAPTURE  ;=  l.OdO  endif 
end 

superclass  USER-OBJECT 


Figure  111  Updated  class  built  for  CAPTURE 


Typically,  the  main  program  is  classified  as  a  Category  1  subprogram.  All  Category  1 
subprograms  other  than  the  main  program  are  transformed  using  the  PBOI  methodology 
defined  for  Category  3  subprograms.  Because  of  the  unique  handling  of  the  main  program, 
the  following  assumption  applies. 

Assumption  V.l.  The  main  program  of  the  system  that  is  being  converted  to  the  object 
paradigm  is  uniquely  identified. 

There  is  no  attempt  in  this  research  to  identify  the  main  program  automatically. 
Since  it  is  at  the  top  of  the  call  tree  of  imperative  subprograms,  such  automatic  identifica¬ 
tion  of  the  main  program  should  be  straightforward  to  implement.  The  main  program  is 
transformed  to  the  object-oriented  paradigm  as  described  in  the  following  section. 


5.8  Converting  the  Main  Program 

The  main  program  of  a  system  provides  a  unique  opportunity  to  update  the  object- 
oriented  design  developed  so  far  and  is  transformed  using  the  rationale  defined  in  this 
section.  Before  the  main  program  is  transformed,  each  of  the  subprograms  called  by  the 
main  program  is  transformed  to  the  object-oriented  paradigm.  This  depth-first  transfor¬ 
mation  results  in  an  object-oriented  design  that  includes  classes  built  for  all  of  the  sub- 
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class  CLASS-4  attributes  RNGFAC,  PROJRA,  SIGB, 

RANGE,  XLAMDA 

method  BOUNCE  (  C-4,  C-6  ):  real 
begin 

RHOSTD  :=  0.95  *  GET-PRO JRA  (  C-4) 

*  GET-ANGFAC  (  C-6); 

BEAMRA  := 

RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE); 

BOUNCE  := 

CAPTURE  (  C-6,  BEAMRA) 

*  RHO  (  RHOSTD,  XLAMDA,  ANGFAC) 

end 

superclass  USER-OBJECT 

Figure  112  Updated  class  built  for  BOUNCE 

programs  in  the  system  (except  the  main  program).  A  special  class  is  built  for  the  main 
program  to  represent  the  overall  system  class  in  the  object-oriented  design.  This  class  has 
no  attributes  and  only  one  method  which  implements  the  main  program.  The  name  of 
this  class  is  CLASS-SYSTEM.  In  this  way,  the  entire  imperative  design  is  converted  into  an 
object-oriented  design  using  depth-first  transformations. 

In  this  research,  an  assumption  is  made  that  all  data  items  in  the  imperative  sub¬ 
programs  are  either  passed  as  parameters  to  the  subprogram  or  declared  locally  in  the 
subprogram;  thus  the  main  program  is  the  origin  of  all  data  items  being  passed  to  the 
imperative  subprograms.  For  this  reason,  the  data  items  in  the  main  program  are  used  to 
create  all  of  the  instances  required  throughout  the  entire  object-oriented  design.  Creating 
every  object  instance  from  data  items  in  the  main  program  leads  to  the  following  thesis. 

Thesis  V.4.  Attributes  that  can  be  linked  to  the  same  main  program  data  item  are  part 
of  the  same  object. 

This  is  used  as  the  rationale  for  two  design  updates  done  at  this  stage  of  the  main 
program  transformation,  as  discussed  in  Section  5.8.1  and  Section  5.8.2. 

Since  each  of  the  subprograms  called  by  the  main  program  has  been  converted  to 
a  method,  the  subprogram  calls  in  the  main  program  must  be  transformed  into  messages 
that  invoke  these  methods.  Each  method  includes  one  or  more  object  instances  in  its 
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class  CLASS-4  attributes  ANGFAC,  RNGFAC,  PROJRA, 
SIGB,  RANGE,  AXMAJ,  AXMIN,  XLAMDA 
method  BOUNCE  (  C-4  ) :  real 
begin 

RHOSTD  :=  0.95  *  GET-PRO JRA  (  C-4) 

*  GET-ANGFAC  (  C-4); 

BEAMRA  := 

RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE); 
BOUNCE  := 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 

*  RHO  (  RHOSTD,  XLAMDA,  ANGFAC) 

end 

superclass  USER-OBJECT 


Figure  113  Initial  class  built  for  BOUNCE 

signature,  so  these  instances  must  be  created  by  the  main  program.  Data  items  which 
appear  as  parameters  in  the  imperative  paradigm  must  be  built  as  attributes  of  object 
instances  in  the  object  paradigm.  The  assignment  statements  that  create  these  instances 
are  inserted  in  the  sequence  of  main  program  statements  just  before  the  message. 

For  example,  Figure  117  shows  the  partial  declaration  of  the  subprogram  LNKCAL- 
DWELLT.  Assume  this  subprogram  is  called  by  the  main  program  BMDSIMl.  The  formal 
parameters  BETA,  XLAMDA,  and  DIAM  are  shown  in  the  figure  as  part  of  the  signature  of  this 
subprogram.  Figure  118  shows  the  partial  declaration  of  the  class  CLASS-20  which  has  the 
method  LNKCAL-DWELLT  that  implements  the  subprogram  LNKCAL-DWELLT  from  Figure  117. 
The  signature  of  the  method  is  radically  different  from  the  signature  of  the  subprogram 
because  the  data  items  BETA,  XLAMDA,  and  DIAM  are  now  attributes  of  a  class  and  do  not 
appear  as  parameters  in  the  signature  of  the  method.  Instead,  an  instance  of  the  class 
that  has  BETA,  XLAMDA,  and  DIAM  as  attributes  is  included  in  the  method  LNKCAL-DWELLT, 
viz.  C-22.  The  instance  object  C-22  is  a  formal  parameter  of  the  method  LNKCAL-DWELLT 
and  a  corresponding  object  must  be  passed  as  an  actual  parameter  of  any  messages  that 
invoke  the  method  LNKCAL-DWELLT.  Since,  in  this  example,  the  LNKCAL-DWELLT  method  is 
invoked  by  the  main  program  BMDSIMl,  the  main  program  must  build  an  instance  to  send 
in  the  message  that  invokes  LNKCAL-DWELLT. 
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class  CLASS-4  attributes  RNGFAC,  PROJRA,  SIGB, 

RANGE,  XLAMDA 

method  BOUNCE  (  C-4,  C-6  ):  real 
begin 

RHOSTD  :=  0.95  *  GET-PRO JRA  (  C-4) 

*  GET-ANGFAC  (  C-6); 

BEAMRA  := 

RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE); 

BOUNCE  := 

CAPTURE  (  C-6,  BEAMRA) 

*  RHO  (  RHOSTD,  XLAMDA,  ANGFAC) 

end 

superclass  USER-OBJECT 

Figure  114  Updated  class  built  for  BOUNCE 

Figure  119  shows  the  class  CLASS-5  that,  in  this  example,  is  the  class  of  which  C-22 
is  an  instance.  Note  the  method  CREATE-CLASS-5  shown  in  the  figure.  This  method 
is  used  to  build  new  instances  of  CLASS-5  and  is  generated  automatically  when  using 
the  PBOI  methodology.  Section  6.11.2  presents  the  transformation  that  formalizes  the 
generation  of  this  method.  Figure  120  shows  the  class  CLASS-SYSTEM  built  for  the  main 
program  BMDSIMl.  Some  of  the  statements  from  the  main  program  are  shown  in  the 
figure.  Specifically,  the  message  that  invokes  the  LNKCAL-DWELLT  method  is  shown,  and 
the  message  that  creates  C-22  is  shown.  Since  C-22  must  be  passed  to  the  LNKCAL-DWELLT 
method,  it  must  first  be  created  and  inserted  into  the  statements  of  the  BMDSIMl  method. 
The  variable  C-22  (a  computer-generated  name)  is  assigned  the  object  instance  returned 
from  the  CREATE-CLASS-5  method  shown  in  Figure  119.  Note  that  the  signature  of  the 
LNKCAL-DWELLT  message  is  incomplete.  If  there  are  any  other  objects  in  the  signature  of  the 
LNKCAL-DWELLT  method,  assignment  statements  are  built  and  inserted  into  the  statements 
of BMDSIMl. 

5.8.1  Removing  Duplicate  Object  Instances.  Following  the  creation  of  object 
instances  and  the  transformation  of  subprogram  calls  into  messages,  the  next  design  update 
is  to  replace  duplicate  object  instances.  Duplicate  object  instances  are  defined  as  follows. 
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class  CLASS-2  attributes  AXMAJ,  AXMIN,  ANGFAC 
method  CAPTURE  (  C-2,  BEAMRA  ):  real 
begin 

TILTFA  ;=  DSIN  (  GET-ANGFAC  (  C-2)); 
RMAREA  :=  GET- AXMAJ  (  C-2)  * 

GET-AXMIN  (  C-2); 

EFAREA  :=  RMAREA  *  TILTFA; 

BMAREA  :=  BEAMRA  *  BEAMRA; 
if  EFAREA  <=  BMAREA  *  6.0d0 
then  USED  ;=  EFAREA  /  BMAREA; 

CAPTURE  ;=  l.OdO  -  DEXP  (  -USED) 
else  CAPTURE  :=  l.OdO  endif 
end 

superclass  USER-OBJECT 


class  CLASS-2  attributes  AXMAJ,  AXMIN,  BEAMRA 
method  CAPTURE  (  C-2,  ANGFAC  ):  real 
begin 

TILTFA  :=  DSIN  (  ANGFAC); 

RMAREA  :=  GET-AXMAJ  (  C-2)  * 

GET-AXMIN  (  C-2); 

EFAREA  :=  RMAREA  *  TILTFA; 

BMAREA  :=  GET-BEAMRA  (  C-2)  *  GET-BEAMRA  (  C-2); 
if  EFAREA  <=  BMAREA  *  6.0d0 
then  USED  :=  EFAREA  /  BMAREA; 

CAPTURE  :=  l.OdO  -  DEXP  (  -USED) 
else  CAPTURE  ;=  l.OdO  endif 
end 

superclass  USER-OBJECT 


Figure  115  Duplicate  classes  built  for  CAPTURE 
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class  CLASS-2  attributes  AXMAJ,  AXMIN 
method  CAPTURE  (  C-2 ,  BEAMRA  ) :  real 
begin 

TILTFA  :=  DSIN  (  ANGFAC) ; 

RMAREA  :=  GET-AXMAJ  (  C-2)  ♦ 

GET-AXMIN  (  C-2); 

EFAREA  :=  RMAREA  *  TILTFA; 

BMAREA  :=  BEAMRA  *  BEAMRA; 
if  EFAREA  <=  BMAREA  *  e.OdO 
then  USED  :=  EFAREA  /  BMAREA; 

CAPTURE  :=  l.OdO  -  DEXP  (  -USED) 
else  CAPTURE  :=  l.OdO  endif 
end 

superclass  USER-OBJECT 


Figure  116  Class  to  replace  the  duplicates 


procedure  LNKCAL-DWELLT  (  ....  BETA,  XLAMDA,  DIAM,  ...  ) 
begin 

end 


Figure  117  Partial  Signature  of  Subprogram  LNKCAL-DWELLT 

Definition  V.6.  Separate  object  instances  that  are  built  from  the  same  class  using  the 
same  data  items  are  duplicate  object  instances. 

Duplicate  object  instances  which  are  identified  in  the  main  program  are  replaced  with  a 
single  object  instance  built  from  the  class.  This  is  done  to  avoid  duplicate  copies  of  the 
instance  attributes  which  may  be  updated  by  different  methods.  Having  duplicate  object 
instances  would  result  in  an  inconsistent  system  state,  so  they  are  eliminated. 

For  example,  Figure  121  shows  the  overall  system  class  CLASS-SYSTEM  built  for  the 
main  program  BMDSIMl.  As  shown  in  the  figure,  the  three  variables  C-22,  C-32,  and  C-36 
are  created  before  being  passed  as  actual  parameters  in  the  LNKCAL-DWELLT  message.  These 
three  variables  are  all  instances  of  CLASS-5,  which  is  also  shown  in  the  figure.  These  in¬ 
stances  are  built  by  using  the  class’s  creation  method,  CREATE-CLASS-5.  All  three  objects 
are  built  from  the  data  items  BETA,  XLAMDA,  and  DIAM,  thus  all  three  objects  are  duplicate 
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class  CLASS-20  attributes  MIRR,  MIRF,  SLACT,  lENG,  SLANG 
method  LNKCAL-DWELLT  (  ...,  C-22,  ....  ) 
begin 

end 


Figure  118  Partial  Signature  of  Method  LNKCAL-DWELLT 


class  CLASS-5  attributes  BETA,  XLAMDA,  DIAM 
method  CREATE-CLASS-5  (  A-BETA,  A-XLAMDA,  A-DIAM  ):  a  CLASS-5 
begin 

INST-CLASS-5  :=  new  (  CLASS-5); 

SET-BETA  (  INST-CLASS-5,  A-BETA); 

SET-XLAMDA  (  INST-CLASS-5,  A-XLAMDA); 

SET-DIAM  (  INST-CLASS-5,  A-DIAM); 

CREATE-CLASS-5  :=  INST-CLASS-5 
end 


Figure  119  Partial  Class  Containing  Attributes  BETA,  XLAMDA,  and  DIAM 

object  instances.  Figure  122  shows  how  method  BMDSIMl  is  updated  by  replacing  the  du¬ 
plicate  object  instances  C-22,  C-32,  and  C-36  with  the  single  instance  C-60.  The  C-60 
instance  is  created  using  the  CREATE-CLASS-5  and  passed  to  the  LNKCAL-DWELLT  method 
in  place  of  C-22,  C-32,  and  C-36.  The  instance  C-60  is  passed  as  three  actual  parameters 
in  order  to  properly  replace  the  object  instances  C-22,  C-32,  and  C-36  in  the  invocation  of 
LNKCAL-DWELLT.  This  allows  the  LNKCAL-DWELLT  method  to  remain  unchanged  and  prop¬ 
erly  refer  to  the  instance  C-60  using  its  three  formal  parameters.  Future  research  should 
explore  the  changes  required  to  methods  such  as  LNKCAL-DWELLT  in  order  to  refer  to  a 
single  formal  parameter  when  eliminating  duplicate  objects. 

5.8.2  Merging  Overlapping  Classes.  The  second  update  done  to  the  design  when 
transforming  the  main  program  is  to  merge  classes  that  overlap. 

Definition  V.7.  A  class  overlaps  another  class  when  an  instance  of  each  class  is  built 
using  at  least  one  common  data  item. 
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class  CLASS-SYSTEM  attributes 
method  BMDSIMl  (  ) 
begin 

C-22  :=  CREATE-CLASS-5  (  BETA,  XLAMDA,  DIAM) ; 
LNKCAL-DWELLT  (  C-46,  C-22,  ...  ); 

end 


Figure  120  Creating  an  Instance  of  CLASS-5 

In  this  case,  the  overlapping  classes  are  merged  into  a  new  class.  The  merging  of  two 
classes  unions  the  attributes  and  operations  of  the  classes  into  a  new  class.  A  single  new 
instance  that  is  built  from  this  new  class  replaces  the  two  separate  instances.  Throughout 
the  entire  design,  any  instances  from  the  overlapping  classes  are  replaced  by  an  instance 
of  the  new  class.  As  with  duplicate  object  instances,  overlapping  classes  are  merged  in 
order  to  avoid  duplicating  instance  attributes  which  may  be  changed  by  different  methods. 
Building  object  instances  from  overlapping  classes  would  result  in  an  inconsistent  system 
state,  so  the  classes  are  merged. 

For  example.  Figure  123  shows  overlapping  classes  CLASS-19  and  CLASS-17  as  well 
as  the  overall  system  class  CLASS-SYSTEM  built  for  the  main  program  BMDSIMl.  As  shown 
in  the  figure,  the  instance  C-56  is  built  as  an  instance  of  CLASS-19  using  the  data  items 
DWELLT  and  NMIRL.  The  instance  C-57  is  built  as  an  instance  of  CLASS-17  using  the  data 
item  DWELLT.  By  Definition  V.7,  classes  CLASS-19  and  CLASS-17  overlap  and  are  merged 
into  one  new  class. 

Figure  124  shows  the  result  of  merging  CLASS-19  and  CLASS-17  into  the  new  class 
CLASS-20.  The  attributes  of  CLASS-20  are  the  union  of  the  attributes  of  CLASS- 19  and 
CLASS-17.  The  names  of  the  attributes  in  CLASS-20  match  the  names  of  the  data  items  in 
the  main  program.  The  attribute  names  are  changed  because  the  names  of  the  attributes 
in  overlapping  classes  do  not  always  match.^  As  shown  in  the  figure,  CLASS-20  includes 

^Recognizing  differently-named  attributes  that  represent  the  same  data  item  is  done  using  the  transitive 
closure  of  the  g  relation,  as  described  in  Section  6.8.2 
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class  CLASS-5  attributes  BETA,  XLAMDA,  DIAM 
method  CREATE-CLASS-5 

(  A-BETA,  A-XLAMDA,  A-DIAM  ):  a  CLASS-5 
begin 

INST-CLASS-5  :=  new  (  CLASS-5); 

SET-BETA  (  INST-CLASS-5,  A-BETA); 
SET-XLAMDA  (  INST-CLASS-5,  A-XLAMDA); 
SET-DIAM  (  INST-CLASS-5,  A-DIAM); 
CREATE-CLASS-5  :=  INST-CLASS-5 
end 


class  CLASS-SYSTEM  attributes 
method  BMDSIMl  (  ) 
begin 

C-22  :=  CREATE-CLASS-5  (  BETA,  XLAMDA,  DIAM); 
C-32  :=  CREATE-CLASS-5  (  BETA,  XLAMDA,  DIAM); 
C-36  :=  CREATE-CLASS-5  (  BETA,  XLAMDA,  DIAM); 

LNKCAL-DWELLT  (  C-46,  C-22,  C-32,  C-36,  ...  ); 


end 


Figure  121  Duplicate  object  instances 

all  of  the  methods  from  CLASS-19  and  CLASS-17.  The  new  instance  C-61  is  created  using 
the  creation  method  from  CLASS-20  and  passed  to  the  LNKCAL-DWELLT  message  in  place  of 
C-56  and  C-57.  The  design  is  updated  by  removing  CLASS-19  and  CLASS-17  and  adding 
CLASS-20.  All  instances  of  the  classes  CLASS-19  and  CLASS-17  are  converted  to  instances 
of  the  class  CLASS-20  throughout  the  entire  design.  In  this  way,  the  design  is  updated  to 
remove  the  overlapping  classes  when  transforming  the  main  program. 


5.9  Converting  Category  4  Subprograms 

Category  4  subprograms  produce  multiple  outputs  without  calling  other  subpro¬ 
grams.  By  using  program  slicing  [22,76],  a  multiple-output  subprogram  is  converted  into 
independent  program  slices  that  each  produce  a  single  output.  These  program  slices  are 
used  to  build  new  imperative  subprograms,  so  a  Category  4  subprogram  is  sliced  into 
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class  CLASS-SYSTEM  attributes 
method  BMDSIMl  (  ) 
begin 

C-60  :=  CREATE-CLASS-5  (  BETA,  XLAMDA,  DIAM) ; 
LNKCAL-DWELLT  (  C-46,  C-60,  C-60,  C-60,  ...  ); 
end 


Figure  122  Duplicates  removed 

multiple  Category  2  subprograms.  This  program  slicing  process  is  discussed  in  detail  in 
Section  5.11. 

5.10  Converting  Category  5  Subprograms 

A  Category  5  subprogram  produces  multiple  outputs  and  calls  other  subprograms.  As 
with  Category  4  subprograms,  program  slicing  is  used  to  convert  a  Category  5  subprogram 
into  multiple  slices.  These  slices  are  used  to  build  new  imperative  subprograms  that  may 
or  may  not  call  other  subprograms,  so  the  Category  5  subprograms  are  sliced  into  new 
subprograms  that  are  classified  as  either  Category  3  or  Category  2  subprograms.  This 
process  of  program  slicing  is  discussed  in  detail  in  Section  5.11. 

5.11  Program  Slicing 

This  section  defines  how  program  slicing  is  used  in  the  PBOI  method  to  simplify  the 
transformation  task.  Program  slicing  has  already  been  defined  in  the  literature  [22,30,76]. 
In  this  research,  a  new  imperative  subprogram  is  built  by  providing  an  appropriate  name 
and  using  a  program  slice  as  the  sequence  of  statements  in  the  subprogram.  The  sequence  of 
formal  parameters  for  this  new  subprogram  consists  of  all  of  the  original  formal  parameters 
that  are  referenced  in  the  program  slice. 

By  using  program  slicing  in  this  way,  the  behavior  of  a  Category  4  or  Category  5 
subprogram  is  projected  into  multiple  subprograms.  Each  of  the  subprograms  produces  one 
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class  CLASS-19  attributes  A,  NVAL 
method  MAXA-NMAX  (  C-45,  NMAX,  AMAX  ) 
begin 

end 

class  CLASS-17  attributes  DWELL! 
method  DASET-DWELLT  (  C-43,  DT,  TLASE) 
begin 

end 


class  CLASS-SYSTEM  attributes 
method  BMDSIMl  (  ) 
begin 

C-56  :=  CREATE-CLASS-19  (  DWELL!,  NMIRL) ; 
C-57  ;=  CREATE-CLASS-17  (  DWELL!  ); 
LNKCAL-DWELL!  (  C-46,  C-56,  C-57); 


end 


Figure  123  Overlapping  object  classes 
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class  CLASS-20  attributes  NMIRL,  DWELL! 
method  CREATE-CLASS-20 

(  A-NMIRL,  A-DWELLT  ):  a  CLASS-20 
begin 

INST-CLASS-20  ;=  new  (  CLASS-20); 
SET-NMIRL  (  INST-CLASS-20,  A-NMIRL); 
SET-DWELLT  (  INST-CLASS-20,  A-DWELLT); 
CREATE-CLASS-20  :=  INST-CLASS-20 
end 

method  MAXA-NMAX  (  C-45,  NMAX,  AMAX  ) 
begin 


end 

method  DASET-DWELLT  (  C-43,  DT,  TLASE) 
begin 


end 


class  CLASS-SYSTEM  attributes 
method  BMDSIMl  (  ) 
begin 

C-61  :=  CREATE-CLASS-20  (  NMIRL,  DWELL!) ; 
LNKCAL-DWELLT  (  C-46,  ...,  C-61,  C-61); 


end 


Figure  124  Overlapping  classes  merged 

of  the  data  items  originally  produced  by  the  Category  4  or  Category  5  subprogram.  Since 
the  PBOI  method  relies  on  the  parameters  being  passed  from  subprogram  to  subprogram 
and  the  new  subprograms  include  only  those  parameters  required  to  produce  the  data  item, 
program  slicing  has  grouped  these  parameters  according  to  how  they  are  used  instead  how 
they  are  organized.  This  new  grouping  helps  the  PBOI  method  move  away  from  the 
structured  analysis  and  design  that  was  done  on  the  original  system  (if  any)  and  move 
towards  an  object-oriented  design. 

For  example,  Figure  125  shows  the  imperative  subprogram  BOOSTR  using  GIL  syntax. 
This  is  a  Category  4  subprogram  because  it  produces  the  two  data  items  R  and  V  and  calls 
no  other  (user-defined)  subprograms.  Figure  126  shows  the  new  imperative  subprogram 
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procedure  BOOSTR  (  ITYPE,  T,  R,  V  ) 
begin 

RE  :=  6378. 16d0; 

PI2  :=  1.570796327d0; 

ITYP  :=  ABS  (  ITYPE); 
if  ITYP  =  1 

then  ALT  :=  -5.71d0  +  (0.24d0  +  0.00363d0  *  T)  *  T; 
RANG  :=  -0.172d0  +  (-0.419d0  +  0.0112d0  *  T)  *  T; 
VEL  :=  -0.196d0  +  (0.0236d0  +  1.6d-6  *  T)  *  T; 
GAMA  ;=  1.12d0  +  (-0.00751d0  +  1.82d-5  *  T)  *  T 
else  endif; 

if  ALT  <  0  then  ALT  :=  0  else  endif; 
if  RANG  <  0  then  RANG  :=  0  else  endif; 
if  GAMA  >  PI2  then  GAMA  :=  PI2  else  endif; 

RM  :=  RE  +  ALT; 

THETA  :=  RANG  /  RE; 

R  (  1)  :=  RM  *  DCOS  (  THETA); 

R  (  2)  :=  RM  *  DSIN  (  THETA); 

R  (  3)  :=  0; 

BETA  :=  THETA  +  PI2  -  GAMA; 

V  (  1)  :=  VEL  *  DCOS  (  BETA); 

V  (  2)  :=  VEL  *  DSIN  (  BETA); 

V  (  3)  :=  0 
end 


Figure  125  Imperative  subprogram  BOOSTR 

built  from  the  program  slice  for  the  data  item  R.  The  name  of  the  subprogram  is  built 
by  appending  the  data  item  identifier  onto  the  name  of  the  original  subprogram,  hence 
the  name  BOOSTR-R.  The  formal  parameters  of  the  new  subprogram  are  the  data  items 
ITYPE,  T,  and  R.  The  new  subprogram  is  classified  as  a  Category  2  subprogram  because 
it  produces  the  single  data  item  R  and  calls  no  other  subprograms.  Figure  127  shows  the 
new  imperative  subprogram  built  from  the  program  slice  for  the  data  item  V.  This  new 
subprogram  is  classified  as  a  Category  2  subprogram  because  it  produces  the  single  data 
item  V  and  calls  no  other  subprograms. 
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procedure  BOOSTR-R  (  ITYPE,  T,  R  )  begin 
RE  :=  6378. 16d0; 

ITYP  :=  ABS  (  ITYPE); 
if  ITYP  =  1 

then  ALT  :=  -5.71d0  +  (0.24d0  +  0.00363d0  *  T)  *  T; 

RANG  :=  -0.172d0  +  (-0.419d0  +  0.0112d0  *  T)  *  T 
else  endif ; 

if  ALT  <  0  then  ALT  :=  0  else  endif; 
if  RANG  <  0  then  RANG  :=  0  else  endif; 

RM  :=  RE  +  ALT; 

THETA  :=  RANG  /  RE; 

R  (  1)  :=  RM  *  DCOS  (  THETA); 

R  (  2)  :=  RM  *  DSIN  (  THETA); 

R  (  3)  :=  0 
end 


Figure  126  Imperative  subprogram  BOOSTR-R 
5.12  Inter- Procedural  Slicing 

When  a  subprogram  being  sliced  includes  calls  to  other  subprograms,  a  more  robust 
program  slicing  process  is  required.  Inter-procedural  slicing  [30]  is  a  special  form  of  program 
slicing  that  builds  a  program  slice  from  a  subprogram  taking  into  consideration  the  calls 
being  made  to  other  subprograms.  Only  the  calls  to  subprograms  that  are  producing  data 
items  required  for  the  slice  are  included  in  the  program  slice. 

This  research  uses  inter-procedural  slicing  when  slicing  Category  5  subprograms.  A 
new  subprogram  is  built  from  the  program  slice  generated,  as  explained  in  Section  5.11. 
For  example.  Figure  128  shows  the  Category  5  subprogram  TRAJ,  which  includes  calls  to 
the  BOOSTR-R  subprogram  and  BOOSTR-V  subprogram.  Originally,  the  TRAJ  subprogram 
called  the  BOOSTR  subprogram.  Because  BOOSTR  is  a  Category  4  subprogram  it  has  already 
been  sliced  and  the  calls  to  the  new  subprograms  have  replaced  the  call  to  BOOSTR.  In  this 
research,  any  calls  in  a  Category  5  subprogram  that  sliced  using  inter-procedural  slicing 
must  produce  a  single  data  item,  i.e.  calls  to  Category  2  or  Category  3  subprograms.  An 
overall  process  that  meets  this  constraint  is  used  to  convert  Category  4  and  Category  5 
subprograms  as  explained  in  Section  5.15.  Since  the  TRAJ  subprogram  includes  the  calls  to 
BOOSTR-R  and  BOOSTR-V,  inter-procedural  slicing  must  be  used.  For  example.  Figure  129 
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procedure  BOOSTR-V  (  ITYPE,  T,  V  )  begin 
RE  :=  6378. 16d0; 

PI2  :=  1.570796327d0; 

ITYP  :=  ABS  (  ITYPE); 
if  ITYP  =  1 

then  RANG  :=  -0.172d0  +  (-0.419d0  +  0.0112d0  *  T)  *  T; 
VEL  :=  -0.196d0  +  (0.0236d0  +  1.6d-6  *  T)  *  T; 

GAMA  :=  1.12d0  +  (-0.00751d0  +  1.82d-5  *  T)  *  T 
else  endif ; 

if  RANG  <  0  then  RANG  :=  0  else  endif; 
if  GAMA  >  PI2  then  GAMA  :=  PI2  else  endif; 

THETA  :=  RANG  /  RE; 

BETA  :=  THETA  +  PI2  -  GAMA; 

V  (  1)  :=  VEL  *  DCQS  (  BETA); 

V  (  2)  :=  VEL  *  DSIN  (  BETA); 

V  (  3)  :=  0 
end 


Figure  127  Imperative  subprogram  BOOSTR-V 

shows  the  result  of  inter-procedural  slicing  the  TRAJ  subprogram  for  the  data  item  R. 
The  TRAJ-R  subprogram  includes  a  call  to  the  BOOSTR-R  subprogram,  but  not  a  call  to 
the  BOOSTR-V  subprogram.  This  is  because  the  data  item  produced  by  the  BOOSTR-V 
subprogram  is  not  needed  for  the  slice  on  data  item  R  in  TRAJ-R.  Figure  130  shows  the 
result  of  inter-procedural  slicing  the  TRAJ  subprogram  for  the  data  item  V.  The  TRAJ-V 
subprogram  includes  a  call  to  the  BOOSTR-V  subprogram  but  not  the  BOOSTR-R  subprogram. 


5.13  Masking  Output  Parameters 

Program  slicing  does  not  always  convert  a  Category  4  or  Category  5  subprogram 
into  a  Category  2  or  Category  3  subprogram.  In  some  cases,  one  output  data  item  must 
be  defined  in  order  to  produce  a  second  output  data  item.  Thus,  if  both  data  items  were 
originally  produced  by  the  subprogram,  then  the  new  subprogram  built  from  a  program 
slice  on  the  second  output  data  item  will  still  include  the  first  output  data  item  and  will 
be  classified  as  either  a  Category  4  or  Category  5  subprogram. 

For  example.  Figure  131  shows  the  Category  4  subprogram  LASP.  This  subprogram 
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procedure  TRAJ 

(  ITYPE,  T,  VI,  RBO,  VBO,  TBO,  TFBOT,  AR,  R,  V  ) 
begin 

XMU  :=  398601. 2d0; 

WDOT  :=  7.292115600000001d-5; 
if  T  <  TBO 

then  BOOSTR-R  (  ITYPE,  T,  RP) ; 

BOOSTR-V  (  ITYPE,  T,  VP); 

MTRT  (  RP,  AR,  RO) ; 

MTRT  (  VP,  AR,  VT); 

TEMP-40  :=  1; 

VADD  (  TEMP-40,  VT,  VI,  VO) 
else  endif ; 

DLONT  :=  -WDOT  *  T; 

TEMP-41  :=  1; 

MAT  (  TEMP-41,  DLONT,  ARL) ; 

MTRT  (  RO,  ARL,  R) ; 

MTRT  (  VO,  ARL,  V) 
end 


Figure  128  Original  imperative  subprogram  TRAJ 

produces  the  data  items  BFLUX,  BFLU,  and  TD.  Figure  132  shows  the  new  subprograms 
LASP-BFLUX,  LASP-BFLU,  and  LASP-TD,  built  from  the  program  slices  for  each  of  these 
three  data  items.  Note  that  the  LASP-TD  subprogram  still  includes  definitions  of  the  BFLUX 
and  BFLU  output  data  items.  In  fact,  there  is  no  difference  between  the  LASP  subprogram 
and  the  LASP-TD  subprogram.  The  new  subprogram  is  still  classified  as  a  Category  4 
subprogram  and  has  not  been  converted  to  a  Category  2  subprogram. 

To  solve  this  problem,  certain  data  items  in  the  new  subprogram  can  be  masked  so 
that  they  are  not  produced  by  the  subprogram.  To  mask  a  data  item,  a  new  local  variable 
is  created  and  any  references  to  the  data  item  are  replaced  with  references  to  the  local 
variable.  Because  of  Restriction  III.l,  the  data  items  being  masked  cannot  be  both  input 
and  output  parameters.  This  means  there  is  no  need  to  initialize  the  local  variable  used 
to  mask  a  data  item.  The  definition  of  the  data  item  becomes  a  definition  of  the  local 
variable,  thus  the  data  item  is  no  longer  produced  by  the  new  subprogram.  Figure  133 
shows  the  LASP-TD  subprogram  after  the  BFLUX  and  BFLU  data  items  have  been  masked. 
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procedure  TRAJ-R 

(  ITYPE,  T,  RBO,  VBO,  TBO,  TFBOT,  AR,  R  ) 
begin 

XMU  :=  398601. 2d0; 

WDOT  :=  7.292115600000001d-5; 
if  T  <  TBO 

then  BOOSTR-R  (  ITYPE,  T,  RP) ; 

MTRT  (  RP,  AR,  RO) 
else  endif ; 

DLONT  :=  -WDOT  *  T; 

TEMP-41  :=  1; 

MAT  (  TEMP-41,  DLONT,  ARL) ; 

MTRT  (  RO,  ARL,  R) 
end 


Figure  129  Imperative  subprogram  TRAJ-R 

These  data  items  still  appear  in  the  signature  of  the  LASP-TD  subprogram  in  order  to 
localize  the  masking  process.  The  identifiers  that  are  used  for  the  formal  parameters  must 
not  match  the  identifiers  used  for  the  local  variables  in  order  to  created  the  disconnect 
that  masks  the  output  parameters. 


5.14  Conservative  Slicing 

By  including  all  statements  from  a  subprogram  that  are  needed  to  produce  a  data 
item,  statements  that  appear  to  be  unnecessary  appear  in  the  program  slice.  For  example, 
Figure  134  shows  the  program  slice  built  for  the  data  item  R  from  the  subprogram  KEP.  The 
second  while  loop  in  the  subprogram  is  unnecessary  code,  but  appears  in  the  program  slice 
because  definitions  of  the  data  item  I  are  required  to  produce  R.  Extra  statements  such 
as  this  while  loop  are  included  in  the  slice  because  this  research  is  using  a  conservative 
approach  to  program  slicing.  There  is  no  attempt  in  the  research  to  optimize  the  slices  or 
filter  unnecessary  statements. 
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procedure  TRAJ-V 

(  ITYPE,  T,  VI,  RBO,  VBQ,  TBO,  TFBOT,  AR,  V  ) 
begin 

XMU  :=  398601. 2d0; 

WDOT  :=  7.292115600000001d-5; 
if  T  <  TBO 

then  BOOSTR-V  (  ITYPE,  T,  VP); 

MTRT  (  VP,  AR,  VT); 

TEMP-40  :=  1; 

VADD  (  TEMP-40,  VT,  VI,  VO) 
else  endif ; 

DLONT  :=  -WDOT  *  T; 

TEMP-41  ;=  1; 

MAT  (  TEMP-41,  DLONT,  ARL) ; 

MTRT  (  VO,  ARL,  V) 
end 


Figure  130  Imperative  subprogram  TRAJ-V 


procedure  LASP 

(  POWL,  EFFNCY,  AREA,  CFLUM,  CFLUS,  XKF,  BFLUX,  BFLU,  TD  ) 
begin 

BFLUX  :=  EFFNCY  *  POWL  /  AREA; 

BFLU  :=  CFLUM  +  XKF  *  CFLUS; 

TD  :=  BFLU  /  BFLUX 
end 


Figure  131  Imperative  subprogram  LASP 
5.15  Slicing  for  the  Main  Program 

This  section  defines  the  overall  process  used  to  ensure  all  Category  4  and  Category 
5  subprograms  are  converted  to  Category  2  or  Category  3  subprograms.  The  overall 
collection  of  imperative  subprograms  to  be  converted  to  the  object-oriented  paradigm  is 
stored  in  a  structured  design,  as  described  in  Section  3.7. 

The  first  step  in  this  process  is  to  build  a  program  slice  for  each  of  the  data  items 
produced  by  a  Category  4  or  Category  5  subprogram.  Inter-procedural  slicing  is  not  used 
at  this  point.  A  new  subprogram  is  built  for  each  program  slice  and  added  to  the  structured 
design.  Next,  the  original  subprogram  calls  in  all  Category  3,  Category  5,  and  Category  1 
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procedure  LASP-BFLUX  (  FOWL,  EFFNCY,  AREA,  BFLUX  )  begin 
BFLUX  :=  EFFNCY  *  FOWL  /  AREA  end 


procedure  LASF-BFLU  (  CFLUM,  CFLUS,  XKF,  BFLU  )  begin 
BFLU  :=  CFLUM  +  XKF  *  CFLUS  end 


procedure  LASF-TD 

(  FOWL,  EFFNCY,  AREA,  CFLUM,  CFLUS,  XKF,  BFLUX,  BFLU,  TD  ) 
begin 

BFLUX  :=  EFFNCY  *  FOWL  /  AREA; 

BFLU  :=  CFLUM  +  XKF  *  CFLUS; 

TD  :=  BFLU  /  BFLUX 
end 


Figure  132  Imperative  subprogram  LASP-TD 


procedure  LASF-TD 

(  FOWL,  EFFNCY,  AREA,  CFLUM,  CFLUS,  XKF,  BFLUX,  BFLU,  TD  ) 
begin 

LOCAL-1  :=  EFFNCY  *  FOWL  /  AREA; 

LOCAL-2  :=  CFLUM  +  XKF  *  CFLUS; 

TD  :=  LOCAL-2  /  LOCAL-1 
end 


Figure  133  BFLUX  and  BFLU  masked 

subprograms  other  than  the  main  program  are  replaced  by  calls  to  the  new  subprograms 
just  created.  This  means  all  the  original  Category  4  and  Category  5  subprograms  are  still 
in  the  structured  design,  but  the  only  calls  to  such  subprograms  are  in  the  main  program. 

At  this  point,  program  slices  are  built  using  inter-procedural  slicing  for  each  data  item 
produced  by  a  subprogram  that  is  called  from  the  main  program.  New  subprograms  are 
built  from  these  program  slices.  Each  call  to  the  original  subprogram  is  replaced  by  calls  to 
the  new  subprograms.  Note  that  calls  to  Category  0  and  Category  1  subprograms  are  not 
changed.  The  calls  to  Category  2  and  Category  3  subprograms  are  also  not  changed  because 
a  subprogram  built  from  the  program  slice  of  a  Category  2  or  Category  3  subprogram  is 
identical  to  the  original  subprogram. 
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procedure  KEP-R  (  RO,  VO,  T,  XMU,  R  ) 
begin 
I  :=  1; 

while  I  <=  3  do 
begin 

R  (  I)  :=  RO  (  I)  +  VO  (  I); 

I  :=  I  +  1 
end; 

I  :=  1; 

while  I  <=  3  do 
begin 
I  :=  I  +  1 
end 
end 


Figure  134  Imperative  subprogram  KEP-R 

However,  it  is  important  to  use  inter-procedural  slicing  for  Category  3  subprograms 
because  they  are  allowed  to  call  subprograms  from  any  other  category.  The  first  two 
steps  presented  above  ensure  the  calls  to  Category  4  or  Category  5  subprograms  have 
already  been  converted  into  calls  to  new  subprograms.  Inter-procedural  slicing  ensures 
that  only  the  calls  to  subprograms  that  produce  data  items  required  for  the  program  slice 
are  included  in  the  program  slice. 

For  example,  Figure  135  shows  an  alternate  version  of  the  TRAJ  subprogram  that  is 
classified  as  a  Category  3  subprogram  producing  the  single  data  item  R.  By  using  inter¬ 
procedural  slicing  on  this  Category  3  subprogram,  the  subprogram  calls  not  producing  data 
items  for  the  program  slice  are  eliminated.  Figure  136  shows  the  updated  TRAJ  subprogram. 
Note  the  call  to  BOOSTR-R  and  two  calls  to  MTRT  have  been  eliminated.  Subprogram  calls 
such  as  these  constitute  dead  code  [22]  and  are  eliminated  by  inter-procedural  slicing. 

In  the  main  program,  the  calls  to  Category  4  and  Category  5  subprograms  are  re¬ 
placed  with  calls  to  the  new  subprograms  built  from  program  slices.  In  this  way,  none 
of  the  Category  4  or  Category  5  subprograms  are  called  by  any  of  the  subprograms  in 
the  design.  Furthermore,  by  using  inter-procedural  slicing,  all  of  the  subprograms  called 
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procedure  TRAJ 

(  ITYPE,  T,  VI,  RBO,  VBO,  TBO,  TFBOT,  AR,  R  ) 
begin 

XMU  :=  398601. 2d0; 

WDOT  :=  7.292115600000001d-5; 
if  T  <  TBO 

then  BOOSTR-R  (  ITYPE,  T,  RP); 

BOOSTR-V  (  ITYPE,  T,  VP); 

MTRT  (  RP,  AR,  RO) ; 

MTRT  (  VP,  AR,  VT); 

TEMP-40  :=  1; 

VADD  (  TEMP-40,  VT,  VI,  VO) 
else  endif ; 

DLONT  :=  -WDOT  *  T; 

TEMP-41  :=  1; 

MAT  (  TEMP-41,  DLONT,  ARL) ; 

MTRT  (  RO,  ARL,  R) ; 

MTRT  (  VO,  ARL,  V) 
end 


Figure  135  TRAJ  as  a  Category  3  subprogram 

by  the  main  program  produce  exactly  one  data  item.  Several  transformations  have  been 
defined  that  formalize  this  conversion  process.  Chapter  VI  presents  these  transformations. 


5.16  Discussion 

The  conversion  of  imperative  subprograms  to  the  object  paradigm  using  the  PBOI 
methodology  results  in  a  rudimentary  object-oriented  design.  The  inheritance  associa¬ 
tions  are  rudimentary  because  the  inheritance  built  during  the  conversion  is  a  flat  hier¬ 
archy  where  every  class  built  in  the  object  model  inherits  from  the  overall  super  class 
USER-OBJECT.  The  aggregation  associations  are  also  rudimentary  because,  while  allowed, 
aggregation  associations  are  not  identified  by  the  PBOI  methodology.  This  discussion 
leads  to  the  following  limitations  on  the  conversions  from  the  imperative  subprograms  to 
the  object  paradigm. 

Limitation  V.l.  Every  class  in  the  design  extracted  using  the  PBOI  methodology  inherits 
from  the  overall  super-class  USER-OBJECT. 
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procedure  TRAJ 

(  ITYPE,  T,  RBO,  VBO,  TBO,  TFBOT,  AR,  R  ) 
begin 

XMU  :=  398601. 2d0; 

WDOT  :=  7.292115600000001d-5; 
if  T  <  TBO 

then  BOOSTR-R  (  ITYPE,  T,  RP); 

MTRT  (  RP,  AR,  RO) 
else  endif; 

DLONT  :=  -WDOT  *  T; 

TEMP-41  :=  1; 

MAT  (  TEMP-41,  DLONT,  ARL) ; 

MTRT  (  RO,  ARL,  R) 
end 


Figure  136  Updated  Category  3  subprogram  TRAJ 

Limitation  V.2.  Aggregation  associations  are  not  identified  by  the  PBOI  methodology. 

These  two  limitations  are  not  unreasonable.  Future  research  could  possibly  remove 
these  limitations  by  expanding  the  PBOI  methodology. 

5.17  Summary 

This  chapter  has  provided  an  informal  description  of  how  imperative  subprograms 
are  transformed  to  the  object-oriented  paradigm  along  with  some  rationale  for  the  ap¬ 
proach.  The  Parameter-Based  Object  Identification  (PBOI)  method  for  extracting  objects 
from  imperative  subprograms  was  presented.  The  taxonomy  of  imperative  subprograms 
used  to  simplify  the  development  of  the  PBOI  method  was  also  presented.  Each  category 
of  imperative  subprogram  was  explained  and  the  PBOI  transformation  for  converting  that 
category  of  subprogram  to  the  object-oriented  paradigm  was  defined.  The  process  of  con¬ 
verting  Category  4  and  Category  5  subprograms  to  Category  2  and  Category  3  subprograms 
by  using  program  slicing  and  inter-procedural  slicing  was  also  explained.  Transformations 
that  formalize  the  PBOI  method  have  been  defined  and  are  presented  in  the  following 
chapter. 
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VI.  Formal  Transformations 


6. 1  Introduction 

This  chapter  presents  transformations  that  formalize  the  PBOI  methodology,  which 
was  presented  in  Chapter  V.  Proof  that  these  transformations  maintain  functional  equiva¬ 
lence  is  presented  in  Chapter  VII.  Table  1  shows  the  order  in  which  the  transformations  are 
presented  in  the  chapter.  The  transformations  that  convert  statements  and  expressions  are 
presented  first,  since  the  transformations  for  subprograms  build  on  them.  Transformations 
for  each  category  of  subprogram  are  presented  followed  by  the  formalized  transformations 
for  program  slicing.  Finally,  the  transformations  for  the  main  program  are  presented  along 
with  the  transformation  for  the  entire  imperative  design. 

In  order  to  formally  classify  a  subprogram  S,  let  C'atj(S)  indicate  the  category  to 
which  a  subprogram  belongs,  such  that  Cati{S)  is  true  when  5  is  a  Category  i  subprogram. 
Let  Cat  Mis)  indicate  that  the  subprogram  S  is  a  Category  1  subprogram  that  is  also  the 
main  program. 

6.2  Transforming  Statements  (0) 

This  section  defines  the  formal  transformation  for  converting  GIM  statements  to 
GOM  statements.  This  transformation  is  used  when  converting  a  subprogram  to  the  object 
paradigm.  Recall  from  Section  3.24  that  a  GIM  subprogram  is  defined  by  the  following 
tuple. 


<  ids,  Pint  Pouti  P reti  Ploci  ^  ^ 


The  GOM  entity  that  is  analogous  to  a  GIM  subprogram  is  the  method.  In  order  to  convert 
the  GIM  subprogram  to  the  object  paradigm,  the  GIM  subprogram  is  converted  to  a  GOM 
method,  which  is  represented  as  a  tuple  of  the  following  form. 


<  ids )  Qt  art  Qobjf  Qformt  Qreti  Qlocj  ^  > 


159 


Transformation 


Ov  &v 


Oe  Oe 


e 


6e 


6 


Constructs 


variables 


expressions 


statements 


accesses  in  expressions 


variable  accesses 


accesses  in  expressions 


attribute  accesses 


subprograms 


Category  2  subprograms 


parameters  to  attributes 


attributes  to  parameters 


attribute  accesses 


attributes 


known  attributes 


subprograms 


subprograms 


subprogram  calls 


calls  in  expressions 


calls  in  statements 


calls  in  subprograms 


messages  in  methods 


duplicate  classes 


Category  3  subprograms 


Category  1  subprograms 


duplicate  objects 


“GET-”,  “SET-”,  and  “CREATE-”  methods 


classes 


assignment  statements 


main  program  messages 


main  program  messages 


main  program 


program  slices 


main  program  slice  calls 


imperative  design 
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As  an  imperative  subprogram  is  converted  to  an  object-oriented  method,  each  imperative 
statement  in  S  must  be  converted  to  an  object-oriented  statement  in  One  difference 
between  an  imperative  statement  and  an  object-oriented  statement  is  the  way  these  state¬ 
ments  access  data  items.  In  an  imperative  statement,  data  items  are  stored  in  variables 
including  local  variables  and  parameters.  These  variables  are  accessed  by  using  the  name 
of  the  variable.  In  object-oriented  statements,  data  items  may  be  stored  in  attributes  of 
objects.  These  data  items  must  be  accessed  either  directly  by  using  the  name  of  the  at¬ 
tribute  and  the  name  of  the  object  or  indirectly  by  sending  a  message  to  the  appropriate 
object.  Because  of  this  difference,  each  GIM  statement  must  be  converted  to  a  GOM 
statement. 

Part  of  the  conversion  process  is  to  transform  each  GIM  variable  into  a  GOM  variable. 
Let  dy  be  the  transformation  that  converts  a  GIM  variable  into  a  GOM  variable.  Let  v 
be  a  GIM  variable  and  let  v'  be  a  GOM  variable.  In  order  to  formalize  the  conversion,  a 
notation  is  presented  here  that  denotes  the  class  of  AST  that  represents  the  GIM  entity  and 
the  GOM  entity.  For  example,  GOM  variables  are  represented  using  the  gom-variable 
class.  This  is  formalized  by  using  a  boolean  function  named  gom-variable  that  returns 
true  if  the  entity  is  a  gom-variable  and  false  otherwise.  The  9y  transformation  is  defined 
below. 

6y{v)  =  v'  where 

gim-variable(u)  and  gom-variable and 
Vui,  V2 

Svin)  =  9y{v2)  ^  V2 


Since  GIM  input  statements  include  sequences  of  variables,  the  following  transfor¬ 
mation  of  sequences  of  variables  is  presented.  Let  V  represent  a  sequence  of  GIM  variables 
and  let  V'  represent  a  sequence  of  GOM  variables.  Let  pos{v,  V)  represent  the  ordinal 
position  of  the  variable  v  in  the  sequence  V.  The  Oy  transformation  converts  V  to  V  as 
defined  below. 
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OviV)  =  y' where 
'i  veV 

v'  =  6^[v)  and 
v'  G  V  and 

pos(v,V)  =  pos{v',V') 

Another  part  of  the  conversion  process  is  to  transform  each  of  the  GIM  expressions 
into  GOM  expressions.  Let  6^  be  the  transformation  that  converts  a  GIM  expression  into 
a  GOM  expression.  Let  e  be  a  GIM  expression  and  let  e'  be  a  GOM  expression.  The  Og 
transformation  is  defined  as  shown  in  Figure  137. 

GIM  output  statements  include  a  sequence  of  expressions.  In  order  to  transform  such 
sequences,  let  6e  represent  a  formal  transformation  of  a  sequence  of  expressions.  Let  E  be 
a  sequence  of  expressions.  Let  pos{e,E)  represent  the  ordinal  position  of  a  expression  e  in 
the  sequence  of  expressions  E.  The  transformation  is  defined  below. 

Oe{E)  =  E'  where 

W  eeE 

e'  =  de{^)  o,nd 
e'  G  E'  and 

pos{e,E)  =  pos{e',E') 

Let  0  be  a  transformation  that  converts  a  sequence  of  imperative  statements  into 
a  sequence  of  object-oriented  and  imperative  statements.  Let  S  represent  a  sequence  of 
imperative  statements  and  let  represent  a  sequence  of  object-oriented  and  imperative 
statements.  Let  pos{s,  S)  represent  the  ordinal  position  of  a  statement  s  in  the  sequence 
S.  The  9  transformation  uses  the  6y,  9g,  By,  and  Be  transformations  and  is  defined 
as  shown  in  Figure  138.  GIM  procedure  call  statements  are  not  transformed  to  object- 
oriented  statements  by  the  B  transformation.  GIM  function  calls  in  expressions  are  not 
transformed  by  the  Bg  transformation.  This  explains  why  is  a  mixture  of  imperative 
statements  and  object-oriented  statements. 
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9e{e)  —  e'  where 

imperative- variable(e)  e'  —  0„(e)  and 
imperative-function-call(e)  =>•  e'  =  e  and 

imperative-literal-boolean(e)  gom-literal-boolean(e')  and  e  =  e'  and 
imperative-literal-integer(e)  =>  gom-literal-integer(e')  and  e  =  e'  and 
imperative-literal-real(e)  =>  gom-literal-real(e')  and  e  =  e'  and 
imperative-literal-string(e)  gom-literal-string(e')  and  e  =  e'  and 
imperative-addition(e)  and  e  =  <  ei,  +,e2  > 

gom-addition(e')  and  e'  =  <  0e(ei),  +,6e{e2)  >  and 
imperative-and(e)  and  e  =<  a,  and, 62  >  =t* 

gom-and(e')  and  e'  =  <  and,  0e(e2)  >  and 

imperative-concat(e)  and  e  =  <  ei,  &:,e2  > 

gom-concat(e')  and  e'  =  <0e(ei),  &,0e(e2)  >  and 
imperative-division(e)  and  e  =  <  Ci ,  /,  62  >  =>• 

gom-division(e')  and  e'  =  <  9e(ai),  /,6e{e2)  >  and 
imperative-equal(e)  and  e  =  <  ei,  =,62  > 

gom-equal(e')  and  e'  =  <6e{ai),  =,^e(e2)  >  and 
imperative-exponent(e)  and  e  =  <  ei,  **,  62  >  ^ 

gom-exponent(e')  ond  e'  =<de{ai),  **,0e{e2)>  and 
imperative-greater-than-or-equal(e)  and  e  =  <  ei,  >=,62  > 

gom-greater-than-or-equal(e')  and  e'  =  <  0e(ei),  >=,0e(e2)  >  and 
imperative-greater-than(e)  and  e  =  <  ei,  >,  62  > 

gom-greater-than(e')  and  e'  =  <  0e(ei),  >,0e(e2)  >  and 
imperative-less-than-or-equal(e)  and  e  =  <  ei,  <=,62  > 

gom-less-than-or-equal(e')  and  e'  =  <  0e(ei),  <=,9e{a2)  >  and 
imperative-less-than(e)  and  e  =  <  ei,<,e2  > 

gom-less-than(e')  and  e'  =  <  0e(ei),  <,0e(e2)  >  and 
imperative-multiplication(e)  and  e  =  <  ei,  *,e2  >  => 

gom-multiplication(e')  and  e'  =  <  deici),  *,9e(e2)  >  and 
imperative-not-equal(e)  and  e  =  <  61,0,62  >  =^>- 

gom-not-equal(e')  and  e'  =  <  9e(ei),  <>,9e(a2)  >  and 
imperative-or(e)  and  e  =  <  ei,  or,e2  >  ^ 

gom-or(e')  and  e'  =  <  9e{ei),  or,0e(e2)  >  and 
imperative-subtraction(e)  and  e  =  <  ei,  —  ,62  >  =>■ 

gom-subtraction(e')  and  e'  =  <  9e{ei),-,9e{e2)  >  and 
imperative-negate(e)  and  e  =  <  —  ,ei  > 

gom-negate(e')  and  e'  =  <  —,9e{ei)  >  and 
imperative-not(e)  and  e  =  <  not,  a  > 
gom-not(e')  and  e'  =  <  not,0e(ei)  > 

Figure  137  The  9e  transformation 
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0(S)  =  where 
For  each  s  €  S 

imperative-procedure-call(s)  s'  =  s  and 
s  =  <  X,  :=,e>  => 

s'  =  <  6v(x),  :—,de(^)  >  and 
s  =  <  if,  e,  then,  5i ,  else,  S2  >  => 

s'  =  <  if,  0e(e),  then,  0(iSi),  else,  0(S2)  >  and 
s  =  <  while,  e,  S3  >  s'  =  <  while,  Oei^), 
s  =  <  input,  iport,  y  >  ^  s'  —  <  input,  iport,  0y(y)  >  and 
s  —  <  output,  oport,jE  >  s'  =  <  output,  oport,  >  and 

s'  e  and 
pos(s,S)  =  pos{s','9) 

Figure  138  The  0  transformation 
6.3  Transforming  Accesses  (6) 

As  discussed  in  Section  5.3,  when  converting  a  GIM  subprogram  to  the  GOM  using 
the  PBOI  method,  certain  variables  in  the  subprogram  are  converted  to  attributes  of 
the  class  built  for  the  subprogram.  After  a  variable  has  been  converted  to  an  attribute, 
the  statements  in  the  GOM  method  must  be  updated  to  access  the  data  item  from  the 
object  attribute  instead  of  the  variable.  The  formal  transformation  for  converting  variable 
accesses  in  GOM  statements  to  attribute  accesses  of  an  object  is  defined  in  this  section. 

6.3.1  Transforming  Expressions  (6^).  As  part  of  the  conversion  of  variable  ac¬ 
cesses  to  attribute  accesses,  it  is  necessary  to  transform  the  GOM  expressions  found  in 
GOM  statements.  This  section  discusses  a  formal  transformation  of  GOM  expressions 
that  replaces  references  to  variables  with  accesses  of  attributes. 

Let  6e  be  a  transformation  that  converts  an  expression  with  variable  accesses  into 
an  expression  with  object  attribute  accesses.  Let  e  be  a  GOM  expression,  let  c  be  an 
instance  of  a  class  C,  and  let  A  be  a  set  of  GOM  variables.  Let  GET-a  represent  the 
symbol  resulting  from  prepending  “GET-”  to  the  GOM  variable  a.  The  6^  transformation 
is  defined  as  shown  in  Figure  139.  This  transformation  replaces  all  occurrences  of  a  in  the 
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6g(e,c,A)  =  where 

gom-variable(e)  and  e  =  a  and  a  £  A  e'  =  <  GET-a,  [c]  > 

gom-variable(e)  and  e  =  a  and  a  ^  A  ^  e'  =  e  and 

e  =  <  GET-a,  [c\>=^  e'  =  e  and 

gom-function-call(e)  e'  =  e  and 

gom-literal-boolean(e)  =»  e'  =  e  and 

gom-literal-integer(e)  ^  e'  =  e  and 

gom-literal-real(e)  ^  e'  =  e  and 

gom-literal-string(e)  =>  e'  =  e  and 

e  =  <  ei,  -t-,  62  >  =>  e'  =  <  Sgiei),  +,6e{e2)  >  and 

e  =  <  ei,  and,  62  >  ^  =  <  Se{ei),  and,  (5e(e2)  >  and 

6  =  <  61,  &,  62  >  e'  =  <  6e{ei),  (5e(e2)  >  and 

e  =  <  ei,  /,  62  >  =>  e'  =  <  6e(ei),  /,  5e(e2)  >  and 

6  =  <  ei,  =,62  >  e'  =  <  Se{ei),  =,5e(e2)  >  and 

6  =  <  6i,  **,62  >  6'  =  <  5e(ei),  **,<5e(e2)  >  and 

e  =  <  6i,  >=,  62  >  =>  e'  =  <  5e(ei),  >=,^e(e2)  >  and 

6  =  <  6i,  >,  62  >  =4>  6^  =  <  ^e(ei),  >,  5e(62)  >  and 

e  =  <  ei,  <=,  62  >  =>  6'  =  <  ^e(ei),  <=,  ^e(e2)  > 

6  =<ei,<,62>=^  e'  =  <  5e(ei),<,  5e(e2)  >  awci 
e  =  <  61,  *,62  >  =»  e'  =  <  6e{ei),  *,dg{e2)  >  and 
e  =  <  6i,  <>,  62  >  =?►  e'  =  <  Sg{ei),<>,6e{e2)  >  and 
6  =  <  6i,  or,  62  >  =>  ^  =  <  ^e(ei),  or,  ^e(e2)  >  and 
6  =  <  6i,  — ,  62  >  6'  =  <  5e(ei),  — ,^e(e2)  >  and 

6  =  <  — ,6i  >  6^  =  <  —,6e{ei)  >  and 

e  =  <  not,6i  >  e'  =  <  not,6e(ei)  > 

Figure  139  The  6g  transformation 
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expression  e  with  GOM  “GET-”  messages  that  accesses  the  attribute  a  from  the  object 
instance  c.  If  none  of  the  GOM  variables  in  the  set  A  are  part  of  the  expression  e  or  the  set 
A  is  empty,  then  the  original  expression  e  is  returned.  For  example,  the  following  expression 
(shown  in  GOL  syntax)  shows  a  GOM  multiplication  expression  with  the  XLAMDA  and  ZCOS 
variables. 

XLAMDA  *  ZCOS  *  ZCOS  *  ZCOS 

Let  e  represent  this  expression  and  let  C-18  be  an  object  instance  variable.  Consider  the 
following  transformation. 

6eie,  C-18,  {  ZCOS  }) 

This  transformation  replaces  all  variable  accesses  of  ZCOS  in  e  with  messages  that  access  the 
attribute  ZCOS  from  C-18.  The  following  expression  shows  the  result  of  this  transformation. 

XLAMDA  *  GET-ZCOS  (  C-18)  *  GET-ZCOS  (  C-18)  *  GET-ZCOS  (  C-18) 

All  accesses  to  the  data  item  ZCOS  are  now  “GET-”  messages  that  access  the  attribute 
from  C-18. 

6.3.2  Transforming  GOM  Variable  Accesses.  Now  that  accesses  to  variables 
in  expressions  can  be  transformed,  a  formal  transformation  is  presented  that  converts  a 
sequence  of  statements  that  include  variable  accesses  into  a  sequence  of  statements  that 
include  attribute  accesses.  Let  ^  be  a  transformation  that  converts  GOM  variable  accesses 
in  sequences  of  statements  to  GOM  object  attribute  accesses.  Let  'I'  be  a  sequence  of 
GOM  statements,  let  c  be  an  instance  of  a  class  C  and  A  be  a  set  of  GOM  variables.  Let 
SET-a  represent  the  symbol  resulting  from  prepending  “SET-”  to  the  name  of  the  GOM 
variable  a.  Recall  that  the  tuple  <  SET-a,  [c,  e]  >  represents  a  message  named  SET-a 
with  two  parameters,  c  and  e.  Let  instance{c,  C)  represent  whether  or  not  an  object  c  is 
an  instance  of  class  C.  The  6  transformation  is  defined  as  shown  in  Figure  140.  This  is 
a  recursive  transformation  that  uses  the  structure  of  the  GOM  statements  to  transform 
each  access  to  the  GOM  variables  a  in  A  to  GOM  messages  that  access  a  as  an  attribute. 
If  the  statement  in  is  an  assignment  to  a,  then  the  entire  statement  is  transformed  to  a 
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A)  =  where 
instance{c,  C)  and 
C  —  <  idc,^Ci^C-,^> 

V  a  G  A  and  V  s  G 
a  G  o.nd 
s  =  <  a,  :=,  e  >  => 

s'  =  <  SET-a,  [c,  6e(e,  c,  A)]  >  and 
s  =  <  X,  :=,  e  >  and  x  ^  A  ^ 
s'  =  <  X,  :=,Se(e,c,A)  >  and 
s  =  <  if,  e,  then,  S'!,  else,  S2  >  => 

s'  =  <  if,  <5e(e, c.  A),  then, 6(Si,c,  A),  else,  ^(52,c,  A)  >  and 
s  =  <  while,  e,  53  > 

s'  =  <  while, (5e(e, c,  A),d(53,c,  A)  >  and 
s  —  <  output,  oport,E  >  =4> 

s'  =  <  output,  oport,  E'  >  and 
E'  =  [6e{e,c,A)  1  e  G  and 

s'  €^' 


Figure  140  The  6  transformation 

GOM  “SET-”  message.  The  expression  e  in  the  assignment  statement  is  transformed  using 
the  6e  transformation  in  order  to  transform  any  accesses  to  a  in  e.  If  the  statement  is  an 
assignment  to  a  variable  other  than  a,  the  expression  e  must  be  transformed  using  the  6^ 
transformation.  If  the  statement  is  a  selection  statement,  the  expression  e  is  transformed 
by  the  6^  transformation  and  the  sequences  of  statements  Si  and  S2  are  transformed  by 
using  the  6  transformation  recursively.  If  the  statement  is  an  iteration  statement,  the 
expression  e  is  transformed  using  the  Sg  transformation  and  the  sequence  of  statements  S3 
is  transformed  by  using  the  6  transformation  recursively.  If  the  statement  is  an  input  or 
an  output  statement,  then  the  sequence  of  expressions,  E,  in  the  statement  is  transformed 
by  using  the  Sg  transformation  on  each  of  the  expressions  in  the  sequence.  If  none  of  the 
GOM  variables  in  the  set  A  are  accessed  in  the  statements  in  ^  or  the  set  A  is  empty,  then 
the  original  statements  in  ^  are  returned  unchanged. 
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6.S.3  Transforming  Attribute  Accesses  (S~^).  As  part  of  the  PBOI  method,  in 
some  cases  it  is  necessary  to  convert  an  attribute  of  a  class  back  into  a  formal  parameter 
of  a  method.  In  this  case,  the  attribute  accesses  must  be  converted  back  to  accesses  of  a 
variable  since  a  formal  parameter  in  a  method  is  a  variable  defined  by  the  method.  This 
means  the  6  and  8^  transformations  must  be  reversible. 

Let  8~^  be  a  transformation  that  converts  object  attribute  accesses  in  GOM  expres¬ 
sions  to  variable  accesses.  Let  e  be  a  GOM  expression,  let  c  be  an  instance  of  a  class 
C,  and  let  A  be  a  set  of  GOM  variables.  Let  GET-a  represent  the  symbol  resulting  from 
prepending  “GET-”  to  the  GOM  variable  a.  The  S~^  transformation  is  defined  as  shown 
in  Figure  141.  This  transformation  replaces  all  occurrences  of  GOM  “GET-”  messages 
that  access  the  attribute  a  in  the  expression  with  a  reference  to  a.  If  none  of  the  GOM 
variables  in  the  set  A  are  part  of  the  expression  e  or  the  set  A  is  empty,  then  the  original 
expression  e  is  returned. 

The  inverse  of  the  transformation  of  statements  is  defined  below.  Let  <5“^  be  a  trans¬ 
formation  that  converts  GOM  object  attribute  accesses  in  statements  to  GOM  variable 
accesses.  Let  'S'  be  a  sequence  of  GOM  statements,  let  c  be  an  instance  of  a  class  C  and 
A  be  a  set  of  GOM  variables.  Let  SET-a  represent  the  symbol  resulting  from  prepend¬ 
ing  “SET-”  to  the  name  of  the  GOM  variable  a.  The  8~^  transformation  is  defined  as 
shown  in  Figure  142.  This  is  a  recursive  transformation  that  uses  the  structure  of  the 
GOM  statements  to  transform  each  attribute  access  of  a  into  a  reference  to  the  variable 
a.  If  the  statement  in  is  a  “SET-”  message  that  sets  the  value  of  a,  then  the  “SET-” 
message  is  replaced  with  an  assignment  statement  that  sets  the  value  of  the  variable  a. 
The  expression  e  from  the  message  is  transformed  using  the  8~^  transformation  in  order 
to  transform  any  accesses  of  a.  If  the  statement  is  an  assignment  to  a  variable  other  than 
a,  the  expression  e  must  be  transformed  using  the  transformation.  If  the  statement 
is  a  selection  statement,  the  expression  e  is  transformed  by  the  transformation  and 
the  sequences  of  statements  Si  and  52  are  transformed  by  using  the  transformation 
recursively.  If  the  statement  is  an  iteration  statement,  the  expression  e  is  transformed 
using  the  transformation  and  the  sequence  of  statements  S3  is  transformed  by  using 
the  5“^  transformation  recursively.  If  the  statement  is  an  input  or  an  output  statement. 
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6~^{e,c,A)  =  e' where 

e  =  <  GET-a,  [c]  >  and  a  £  A  gom-variable(e')  and  e'  =  a  and 

e  =  <  GET-a,  [c]  >  and  a  ^  A  e'  =  e  and 

gom-variable(e)  e'  =  e  and 

gom-function-call(e)  ^  e'  =  e  and 

gom-literal-boolean(e)  e'  =  e  and 

gom-literal-integer(e)  e'  =  e  and 

gom-literal-real(e)  e'  =  e  and 

gom-literal-string(e)  ^  e'  =  e  and 

e  =  <  ei,  +,62  >  =>  e'  =  <  S~^{ei),  +,^"^(62)  >  and 
e  =  <  ei,  and,  62  >  =»  e'  =  <  6~^{ei),  and,  ^“^(62)  >  and 
e  =  <  61,  62  >  e'  =  <  S~^{e\),  5“^(62)  >  and 

6  =  <  61,  /,62  >  6'  =  <  6~^{ei),  /,6~^{e2)  >  and 

6  =  <  61,  =, 62  >  =>  e'  =  <  =,(5“^(62)  >  and 

6  =  <  ei,  **,62  >  =»  e'  =  <  **,S~^{e2)  >  and 

6  =  <  61,  >=,62  >  =»  e'  =  <  6~^{ei),>=^8~^{e2)  >  and 
e  =<6i,>,62>^  e'  =  <  57^(ei), >, ^“^(62)  >  and 
6  =  <  61,  <=,  62  >  =>  e'  =  <  8~^{ei),<=,6~^{e2)  >  and 
6  =<6i,<,62>=>  e'  =  <  <,^7^(62)  >  and 

6  =  <  61,  *,62  >  =»  e'  =  <  ^7^ (^1)5  >  and 

e  =<  61,0,62  >=^  e'  =  <  8~^{ei),<>,6~^{e2)  >  and 
e  =  <  61,  or,  62  >  e'  =  <  8~^{ei),  or,  ^“^(62)  >  and 
e  =<6i,-,e2>^  e'  =  <  6“^(ei),  — , ^“^(62)  >  and 
e  =  <  — ,61  >  =>  e'  =  <  — >  ^nd 
e  —  <  not,  61  >  =>  e'  =  <  not,  5"^(6i)  > 

Figure  141  The  6~^  transformation 
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c,  A)  =  where 
V  a  G  A  and  V  s  G 

s  =  <  SET-a,  [c,  e]  >=> 

s'  =<  a,  :=,6~^(e,c,A)  >  and 
s  =  <  X,  :=,e  >  => 

s'  =  <  X,  :=,6~^{e,c,A)  >  and 
s  =  <  if,  e,  then,  5i,  else,  52  > 

s'  =  <  if,  ^“^(e,c,  vl),  then,  ^~^(5i,  c,  A),  else,  (5'“^(52,  c,  A)  >  and 
s  =  <  while,  e,  53  > 

s'  =  <  while, c,  A), ^“^(53, c,  A)  >  and 
s  =  <  input,  iport,  E  > 

s'  =  <  input,  iport,  E'  >  and 
E'  =  [6~^{e,c,A)  \  e  E  E\  and 
s  —  <  output,  oport,  E  >  ^ 

s'  —  <  output,  oport,  E'  >  and 
E'  =  [8~^{e^c,A)  1  e  G  E]  and 

s'  E^' 


Figure  142  The  6  ^  transformation 

then  the  sequence  of  expressions,  E,  in  the  statement  is  transformed  by  using  the  6^^ 
transformation  on  each  of  the  expressions  in  the  sequence.  If  none  of  the  GOM  variables 
in  the  set  A  are  accessed  in  the  statements  in  ^  or  the  set  A  is  empty,  then  the  statements 
in  are  returned  unchanged. 


6.4  Transforming  Subprograms  (a) 

This  section  defines  the  high-level  transformation,  a,  that  applies  lower-level  transfor¬ 
mations  to  formalize  the  PBOI  method  defined  in  Section  5.3.  The  a  transformation  uses 
the  taxonomy  of  GIM  subprograms  defined  in  Section  5.2  to  classify  the  input  subprogram 
and  apply  the  transformation  appropriate  for  that  category  of  subprograms. 

Let  5  represent  an  imperative  subprogram  and  OOD  represent  the  object-oriented 
design  developed  so  far.  The  a  transformation  is  defined  as  follows. 
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a{OOD,S)  =  OOD' where 

Cato{S)  OOD'  =  a2(OOD,  S)  and 

Cati{S)  ^OOD'  =  ai{OOD,S)  and 

Cat2{S)  =>OOD'  =  a2{OOD,S)  and 

Catz{S)  =^OOD'  =  (Jz{OOD,S) 

Note  that  Category  0  subprograms  are  treated  as  a  special  case  of  Category  2  sub¬ 
programs,  so  the  <72  transformation,  defined  in  the  following  section,  is  used  to  transform 
both  Category  0  and  Category  2  subprograms.  The  transformations  for  Category  1  and 
Category  3  subprograms  are  defined  in  Section  6.8.  The  transformations  that  formalize 
the  program  slicing  process  used  to  convert  Category  4  and  Category  5  subprograms  are 
defined  in  Section  6.12. 

6.5  Transforming  Category  2  Subprograms  ((12) 

This  section  describes  the  formal  transformation  of  Category  2  subprograms  to  the 
object  paradigm.  As  defined  in  Section  5.3,  the  PBOI  method  assumes  Category  2  subpro¬ 
grams  implement  derived  attribute  queries.  According  to  Proposition  V.2,  each  Category  2 
subprogram  is  converted  to  a  method  in  a  class  where  the  attributes  of  the  class  are  built 
from  the  formal  parameters  of  the  Category  2  subprogram  (see  Section  5.3). 

The  formal  transformation  <72  transforms  an  imperative  subprogram,  S,  into  a  class, 
C,  which  includes  a  method  that  implements  S.  The  new  class,  C,  is  added  to  the  object- 
oriented  design  developed  so  far,  OOD,  and  an  updated  design  OOD'  is  returned  from  the 
transformation. 

Let  idc  be  a  symbol  representing  the  name  of  the  newly  formed  class  C.  This  symbol 
can  be  a  computer  generated  one  or  can  be  provided  by  the  user.  Let  Aq  be  a  symbol  that 
represents  the  name  of  the  overall  super-class  (  ’USER-OBJECT  )  from  which  every  object 
inherits  in  the  design  being  developed.  Let  c  represent  a  parameter  that  holds  an  instance 
of  the  class  C.  Then,  the  transformation  <72  for  a  Category  2  subprogram  S  is  defined  as 
follows. 
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a2{OOD,  S)  =  OOD'  where 

S  =  <  ids  j  Pirn  Poutt  Preti  Ploci  ^  CLTld 
P form  ~  Pin  ^  Pout  G/nd 

C  =  <  idc,^C)^Ci^o  > 

=  range{ev{Pform))  o^nd 

Qret  ~  ^v(^Pret)  o/nd 
Qloc  “  ^vi^Ploc)  (tfid 

—  S{6{Y,s),c,^c)  (tnd 

^  i^S  ^  Qrcty  Qlocy'^  C  ^  dTld 

OOD'  =  T+{OOD,C) 

This  transformation  builds  an  object-oriented  class  C  from  the  imperative  subpro¬ 
gram  S  by  first  transforming  all  the  input  parameters  in  Pin  and  output  parameters  in  Pgut 
into  instance  attributes,  ^Cy  of  C  by  using  the  Oy  transformation.  The  return  value  and 
the  local  variables  are  also  converted  to  GOM  variables  using  By-  The  newly  formed  class 
C  is  a  subclass  of  Aq  and  includes  one  method  in  fie  that  implements  the  functionality 
of  the  imperative  subprogram.  The  newly  formed  method  is  named  using  the  name  of 
the  imperative  subprogram  ids.  The  method  must  be  passed  an  instance  of  the  class  C 
as  the  target  object  and  is  not  passed  any  other  objects  or  input  or  output  parameters. 
Each  statement  of  the  subprogram  in  E5  is  transformed  into  an  object-oriented  statement 
using  the  9  transformation.  In  these  statements,  all  accesses  to  the  variables  that  are  now 
included  in  are  changed  to  accesses  of  these  attributes  by  using  the  6  transformation. 
The  new  class  C  is  added  to  the  object  design  by  using  the  T^{OOD,  C)  transformation. 

6.6  Transforming  Parameters 

This  section  presents  formal  transformations  for  manipulating  parameters  of  methods 
and  attributes  of  classes.  As  presented  in  Section  5.3,  in  some  cases  when  using  the  PBOI 
method  it  is  necessary  to  add  or  remove  attributes  of  classes.  In  order  to  maintain  the 
visibility  to  the  data  item,  an  attribute  removed  from  a  class  is  added  as  a  parameter  to  each 
method  of  the  class.  Conversely,  when  an  attribute  is  added  to  a  class  the  corresponding 
parameter  is  removed  from  each  of  the  methods  of  the  class. 
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For  these  reasons,  formal  transformations  that  convert  parameters  of  the  methods  of 
a  class  into  attributes  of  that  class  (and  vice  versa)  have  been  developed.  The  transforma¬ 
tions  presented  in  Section  4.32  for  adding  and  removing  an  attribute  of  a  class  (T+  and 
T~ )  are  sufficient  for  developing  a  design,  but  are  not  rigorous  enough  for  re-engineering. 
They  do  not  consider  the  effects  on  the  methods  of  a  class  that  adding  or  removing  an 
attribute  will  have.  The  transformations  and  T~  will  not  be  used  when  converting 
GIM  subprograms  to  the  GOM.  Instead,  the  following  transformations  will  be  used  to  add 
and  delete  attributes  of  a  class. 

6.6.1  Moving  Parameters  to  Attributes  (T^).  Let  be  a  transformation  that 
moves  parameters  of  the  methods  of  a  class  to  attributes  of  the  class.  Let  OOD  represent  an 
object-oriented  design,  let  C  represent  a  class,  and  let  A  represent  a  set  of  GOM  variables 
to  be  converted  from  parameters  to  attributes.  Let  seq{A)  represent  the  conversion  of  the 
set  A  to  a  sequence  of  arbitrary  order.  The  transformation  is  defined  as  shown  below. 

Ti{OOD,C,A)  =  C' where 
C  —  <.  idc,  ^ 

^'c  —  0  A  and 

For  each  o  €  Clc 

O  —  K.  idg^  C,  QobjiQ  formiQretjQlocy^  ^  and 
o  —  idg^CiQobj  yQ  form  Q  Qret)  Qlocj  ^  and 

o'  €  and 

C  =  <  idc,  ^  ^ 

In  this  transformation,  the  attributes  in  A  are  added  to  the  set  of  attributes  for 
the  class,  i.e.  ^c-  Each  method  o  of  the  class  C  is  transformed  by  using  the  sequence 
subtraction  operation  ©  to  ensure  the  data  items  in  A  are  not  in  the  sequence  of  formal 
parameters.  All  accesses  to  the  data  items  in  A  in  the  statements  of  o'  are  transformed  to 
attribute  accesses  of  c  using  the  6  transformation  (see  Section  6.3).  If  the  set  A  is  empty, 
then  the  transformation  adds  no  attributes  and  changes  no  statements,  so  the  class  C 
is  not  changed  by  the  transformation.  The  transformed  class  C  is  returned  as  the  result 
of  the  transformation. 
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6.6.2  Moving  Attributes  to  Parameters  (T^  ^ ).  When  using  the  PBOI  method,  it 
is  also  necessary  to  transform  attributes  of  classes  into  parameters  of  its  methods.  For  this 
reason,  the  “inverse”  of  the  transformation  is  defined.  Let  ^  be  a  transformation 
that  converts  a  set  of  attributes  of  a  class  into  parameters  of  the  methods  of  the  class. 
Let  OOD  represent  an  object-oriented  design,  let  C  represent  a  class,  and  let  A  represent 
a  set  of  data  items  to  be  converted  from  attributes  to  parameters.  Let  seq(A)  represent 
the  conversion  of  the  set  .A  to  a  sequence  of  arbitrary  order.  The  transformation  is 
defined  as  follows. 

Ti~\00D,C,A)  =  C' where 
C  =  <  idc,^C:^Ci  ^ 

—  A  and 

For  each  o  €  ftc 

o  =  <  ido,c,Qoi)j,Qfoj.ffi,Qj.gt,Qio(.,^  >  and 

O  —  ^  idpy  C,  Qobj )  Q fortn  ^  ^  Qrett  Qloc^  ^  '^)  ^  and 

o'  G  (I'c  and 

C'  =  <.  idct^'ci^'ci^  ^ 

In  this  transformation,  the  attributes  in  A  are  removed  from  the  set  of  attributes 
for  the  class,  ^c-  Each  of  the  methods  in  the  class  are  transformed  by  adding  the  data 
items  in  A  as  parameters  of  o' .  Finally,  the  transformation  is  used  to  convert  all 
attribute  accesses  in  the  statements  of  o'  to  variable  accesses.  If  the  set  A  is  empty,  then 
the  ^  transformation  removes  no  attributes  and  changes  no  statements,  so  the  class  C 
is  not  changed  by  the  transformation.  The  updated  class  C  is  returned  as  the  result  of 
the  transformation.  Note  that  the  transformation  and  the  ^  transformation  are  not 
true  inverses  because  ^  {^^{OOD,C,A),C,A)  ^  C.  This  is  because  the  order  of  some 
parameters  may  have  changed. 

6.7  Transforming  Attributes  ('y) 

This  section  defines  a  formal  transformation  for  moving  an  attribute  from  one  class 
to  another.  In  some  cases  when  using  the  PBOI  method  (see  Section  5.3),  it  may  be 
determined  that  a  parameter  should  be  built  as  an  attribute  of  one  class  instead  of  another. 
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To  formalize  this  case,  a  transformation  is  needed  that  moves  an  attribute  from  one  class 
to  another.  This  section  presents  this  formal  transformation  and  a  simplified  version  of 
the  transformation. 

To  define  the  transformation  that  moves  an  attribute  from  one  class,  Ci,  to  another 
class,  C2,  a  transformation  is  needed  that  replaces  instances  of  Ci  with  instances  of  C2  in 
any  messages  where  Ci  is  the  target  object.  Let  7  be  a  transformation  that  changes  all 
attribute  accesses  of  specific  attributes  from  an  instance  of  one  class  to  an  instance  of  a 
second  class.  Let  A  he  a  subset  of  attributes  from  a  class  Ci.  Let  ci  be  an  instance  of  Ci 
and  C2  be  an  instance  of  the  class  C2.  Let  vp  be  a  sequence  of  object-oriented  statements. 
Then, 


=  7(^,ci,C2,^) 

where  'if'  is  a  sequence  of  object-oriented  statements  where  all  attribute  accesses  of  the 
attributes  in  A  from  the  instance  ci  are  now  attribute  accesses  of  the  attributes  in  A  for 
the  instance  C2. 

For  example,  consider  the  following  statement 

X  :=  GET-BETA  (  C-8  ) 

The  following  transformation 

7([  X  :=  GET-BETA  (  C-8  )  ],  C-8,  C-9,  {  BETA}) 

results  in  the  following  updated  statement 

X  :=  GET-BETA  (  C-9  ) 

The  access  of  BETA  now  comes  from  C-9  instead  of  C-8. 

Using  the  7  transformation,  it  is  now  possible  to  define  the  Tj  transformation  that 
moves  attributes  from  one  class  to  another.  Let  OOD  represent  an  object-oriented  design, 
let  Cl  be  a  class,  let  ci  be  an  instance  of  Ci,  let  C2  be  a  class,  and  let  C2  be  an  instance 
of  C2.  Let  A  be  a  set  of  attributes  of  Ci  that  will  be  moved  from  Ci  to  C2.  The  Tj 
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transformation  assumes  that  the  instance  ci  is  passed  as  a  parameter  to  the  methods  of 
the  class  C2  in  order  to  have  visibility  to  the  attributes  in  A.  The  transformation  is 
defined  as  follows. 


Tl{OOD,CuC2,A)  =  00 D' where 
Cl  =  <  idci )  ^Ci ,  )  ^Ci  >  o,nd 

instance{ci,Ci)  and 
C2  =  <idc2,^C2,^C2',^C2  >  and 
instance(c2,C2)  and 
^Ci  =  ^Ci  -  A  and 
^C2  =  U  A  and 
For  each  o  €  fici 

o  =  <  idg,  Cl,  QqIjj^Q >  and 
O  —  ^  ido,  Cl,  Qoijj  ®  \c2\,  Q formj  Qret^  Qlocf'yi,^ i  ai,  C2,  A')  >  and 
o'  €  and 
For  each  o  €  Oca 

o  =  <  ido,C2,QobjiQ f  ormy  Qreti  Qloci  ^  ^  and 
0  =  idg,  C2,Qobj)Q  formtQretiQlocf  “yi^  i  ai,  C2,  A)  >  and 

o'  G  fl^a 

C'l  =  <  idci ,  $ci )  ^Ci » >  and 
C2  =  <  idcai^CaJ^CaJ^Ca  >  and 
COD'  =  T+{T-{T+{T-{OOD,Ci),C'i),C2),C'2) 


This  transformation  removes  the  attributes  in  A  from  Ci  and  adds  them  to  the  set  of 
attributes  in  C2.  Each  method  in  Ci  is  updated  by  adding  the  instance  C2  to  the  sequence 
of  objects  passed  into  the  method.  The  statements  of  each  method  are  changed  by  the 
7  transformation  to  send  any  accessing  and  assigning  messages  to  C2  instead  of  ci.  The 
statements  of  each  method  are  changed  by  the  7  transformation  to  also  send  any  accessing 
and  assigning  messages  to  C2  instead  of  ci.  The  methods  in  both  Ci  and  C2  now  access 
the  attributes  in  A  from  the  instance  C2.  If  the  set  A  is  empty,  then  the  transformation 
moves  no  attributes  and  neither  Ci  nor  C2  are  changed  by  the  transformation.  The  updated 
classes  are  added  to  the  design  OOD  in  order  to  produce  the  updated  design  OOD' . 

As  an  example,  Figure  143  shows  an  object-oriented  design  with  two  classes  where 
the  GOM  variable  DIAM  is  an  attribute  of  CLASS-4.  The  PRDIV  method  is  passed  C-9,  an 
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instance  of  CLASS-4,  in  order  to  access  the  DIAM  attribute.  Figure  144  shows  the  result  of 
the  transformation 


TliOOD,  CLASS-4,  CLASS-5,  DIAM) 

The  DIAM  attribute  has  been  moved  from  CLASS-4  to  CLASS-5  and  the  methods  have  been 
updated  to  reflect  this  change. 

The  T2  transformation  can  be  simplified  if  it  is  known  that  the  attributes  in  A  are 
already  attributes  of  C2  and  the  desired  processing  is  to  make  appropriate  updates  to  Ci. 
Given  this  precondition,  define  as  follows. 

T]^iOOD,Ci,C2,A)  =  C;  where 

Cl  =  <  idci ,  $Ci ,  ^Ci ,  ^Ci  >  o,nd 
instance{ci,Ci)  and 
instance{c2,C2)  and 
^Ci  ~  ^Ci  -  A  and 
For  each  o  €  flci 

o  =  <  idojCi,Qoi)j,Qfo^^,Qrei.^Qioci^  ^  and 
0  =  ^  Cl ,  Qoftj  ©  [C2],  QyoTTTn  Qret )  Qjoc)  t(^)  )  ^2)  A)  >  and 

o'  € 

C'l  =  <  idc^ ,  > 

Since  it  is  assumed  that  the  attributes  in  A  have  already  been  built  as  attributes  of 
C2,  this  transformation  removes  the  attributes  from  the  set  of  attributes  for  Ci  but  makes 
no  change  to  the  set  of  attributes  for  C2.  Similarly,  only  the  methods  of  Ci  are  updated 
to  access  the  attributes  in  A  from  C2  instead  of  ci.  The  methods  in  C2  are  assumed  to 
already  access  the  attributes  from  C2.  If  the  set  of  attributes  A  is  empty,  then  the 
transformation  removes  no  attributes,  so  Ci  is  not  changed  by  the  transformation.  The 
updated  class  Ci  is  returned  as  the  result  of  this  transformation. 

For  example.  Figure  145  shows  the  DIAM  attribute  as  an  attribute  of  both  CLASS-4  and 
CLASS-5.  This  attribute  is  being  accessed  correctly  in  CLASS-5  and  moving  the  attribute 
from  CLASS-4  to  CLASS-5  is  a  matter  of  making  the  correct  updates  to  CLASS-4.  Figure  146 


177 


class  CLASS-4  attributes  DIAM,  UPLFAC,  ZENITH 
method  RELAY-PHASE  (  C-8,  PHASE  ) 
begin 

PHASE  :=  1; 

SIGPR  :=  GET-DIAM  (  C-8  ) ; 

PHASE  :=  UPLREQ  (  SIGPR  ) 
end 

superclass  USER-OBJECT 


class  CLASS-5  attributes  BETA,  XLAMDA 
method  PRDIV  (  C-3 ,  C-9  ) :  real  begin 
FAC  :=  1.22d0; 

QUAL  :=  MAX  (  GET-BETA  (  C-3),  l.OdO); 
PDIAM  :=  MAX  (  GET-DIAM  (  C-9),  O.ldO); 
WAVELN  :=  GET-XLAMDA  (  C-3)  *  9.9d-7; 
PRDIV  ;=  QUAL  *  WAVELN  *  FAC  /  PDIAM 
end 

superclass  USER-OBJECT 


Figure  143  DIAM  as  Attribute  of  CLASS-4 


class  CLASS-4  attributes  UPLFAC,  ZENITH 
method  RELAY-PHASE  (  C-8,  C-9,  PHASE  ) 
begin 

PHASE  :=  1; 

SIGPR  :=  GET-DIAM  (  C-9  ) ; 

PHASE  :=  UPLREQ  (  SIGPR  ) 
end 

superclass  USER-OBJECT 


class  CLASS-5  attributes  BETA,  XLAMDA,  DIAM 
method  PRDIV  (  C-3  ) :  real  begin 
FAC  :=  1.22d0; 

QUAL  :=  MAX  (  GET-BETA  (  C-3),  l.OdO); 
PDIAM  :=  MAX  (  GET-DIAM  (  C-3),  O.ldO); 
WAVELN  :=  GET-XLAMDA  (  C-3)  *  9.9d-7; 
PRDIV  :=  QUAL  *  WAVELN  *  FAC  /  PDIAM 
end 

superclass  USER-OBJECT 


Figure  144  DIAM  as  Attribute  of  CLASS-5 
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class  CLASS-4  attributes  DIAM,  UPLFAC,  ZENITH 
method  RELAY-PHASE  (  C-8,  PHASE  ) 


begin 

PHASE 

:=  1; 

SIGPR 

:=  GET-DIAM 

(  C-8  ); 

PHASE 

end 

:=  UPLREQ  ( 

SIGPR  ) 

superclass  USER-OBJECT 


class  CLASS-5  attributes  BETA,  XLAMDA,  DIAM 
method  PRDIV  (  C-3  ) :  real  begin 
FAC  :=  1.22d0; 

QUAL  :=  MAX  (  GET-BETA  (  C-3),  l.OdO); 
PDIAM  :=  MAX  (  GET-DIAM  (  C-3),  O.ldO); 
WAVELN  :=  GET-XLAMDA  (  C-3)  *  9.9d-7; 
PRDIV  :=  qUAL  *  WAVELN  *  FAC  /  PDIAM 
end 

superclass  USER-OBJECT 


Figure  145  DIAM  as  Attribute  of  CLASS-4  and  CLASS-5, 
shows  the  result  of  applying  the  following  transformation 

T]^{OOD,  CLASS-4,  CLASS-5,  DIAM) 

The  DIAM  attribute  is  removed  from  CLASS-4  and  C-9,  the  instance  of  CLASS-5,  is  added 
as  an  object  parameter  to  the  RELAY-PHASE  method.  The  GET-DIAM  message  is  updated 
to  access  DIAM  from  C-9  instead  of  C-8. 
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class  CLASS-4  attributes  UPLFAC,  ZENITH 
method  RELAY-PHASE  (  C-8,  C-9,  PHASE  ) 
begin 

PHASE  :=  1; 

SIGPR  :=  GET-DIAM  (  C-9  ) ; 

PHASE  :=  UPLREQ  (  SIGPR  ) 
end 

superclass  USER-OBJECT 


class  CLASS-5  attributes  BETA,  XLAMDA,  DIAM 
method  PRDIV  (  C-3  ) :  real  begin 
FAC  :=  1.22d0; 

QUAL  :=  MAX  (  GET-BETA  (  C-3),  l.OdO); 
PDIAM  :=  MAX  (  GET-DIAM  (  C-3),  O.ldO); 
WAVELN  :=  GET-XLAMDA  (  C-3)  *  9.9d-7; 
PRDIV  :=  qUAL  *  WAVELN  *  FAC  /  PDIAM 
end 

superclass  USER-OBJECT 


Figure  146  DIAM  as  Attribute  of  CLASS-5 
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6.8  Transforming  Category  3  Subprograms 

This  section  discusses  the  transformations  that  formalize  the  conversion  of  Category 
3  subprograms.  As  defined  in  Section  5.3,  there  are  four  cases  to  consider  when  extracting 
object  attributes  from  the  imperative  subprogram  calls  found  in  Category  3  subprograms. 
Some  fundamental  mappings  required  for  all  the  PBOI  transformations  are  presented  first 
followed  by  the  transformations  that  formalize  each  of  the  four  cases.  The  overall  high- 
level  transformation  that  determines  which  of  these  transformations  to  apply  is  presented 
at  the  end  of  this  section. 

6.8.1  Linking  Classes  and  Subprograms  (p).  In  order  to  build  the  PBOI  trans¬ 
formations,  a  mapping  is  needed  that  links  an  imperative  subprogram  to  the  class  that 
was  built  for  the  subprogram.  Let  p  represent  this  mapping  as  defined  below. 

p{S)  =  C  such  that 

S  —  K.  idg,  Pifi^  Poxif,  >  and 

C  =  <  idc)  -^0  > 

O  =  ids,C,QobjiQformiQret^Qloci^  ^  and 
o  €  fic 

This  mapping  links  the  imperative  subprogram  5  to  a  class  that  has  a  method  o  with 
the  same  name  as  S,  i.e.  ids. 

Since,  at  this  point  in  the  development  of  the  design,  there  is  only  one  class  built 
for  each  subprogram  and  each  class  is  built  from  only  one  subprogram,  the  p  mapping  is 
invertible.  Let  the  p~^  mapping  map  a  class  C  to  the  subprogram  from  which  C  was  built. 
The  p~^  mapping  is  defined  as  follows. 

p~^{C)  =  5  such  that 

C  —  <  zdc,  Ao  >  and 

O  =  ids.,C.,Q(,bjtQ formiQrettQloci^  ^  and 

o  G  etc  o.'iT'd 

S  =  <ids  )  Pirn  P<mti  P reti  Ploc,  S5  > 

This  mapping  links  the  class  C  that  was  built  for  the  subprogram  S  to  this  subprogram  5. 
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Tp\^(OOr>,S,P)  =  OOD' where 
Cl  —  p{S)  and 
VpeP 

P'  =  {p  \  3  C2  E  p*{S)  such  that 
(>■'  =  Qv{P‘*{jp))  and  a'  6  $02  } 

C'l  =  TX{OOD,Ci,C2,0viP'))  and 
C'l  G  COD'  A  Cl  0  COD' 

Figure  147  The  transformation 

6.8.2  Formalizing  PBOI  Case  1.  The  first  case  for  converting  Category  3  sub¬ 
programs  is  that  the  formal  parameter  is  an  attribute  and  the  actual  parameter  is  also 
a  formal.  This  section  develops  the  transformation  that  formalizes  the  PBOI  Case  1  as 
presented  in  Section  5.3.  When  transforming  a  subprogram  5,  the  transformation  required 
for  PBOI  Case  1  is  to  move  attributes  from  the  class  built  for  S  to  another  class  in  the 
design.  This  transformation  is  done  on  any  of  the  formal  parameters  in  5  that  can  be 
linked  to  the  attributes  of  another  class  through  the  9y  transformation  and  the  p*  relation. 
An  example  is  given  at  the  end  of  the  section. 

Let  be  the  transformation  that  formalizes  the  first  PBOI  case.  Recall  from 
Section  3.25,  the  p  relation  maps  an  actual  parameter  of  a  subprogram  call  to  a  formal 
parameter  in  the  called  subprogram.  Let  p*  represent  the  transitive  closure  of  the  p 
relation.  Let  call{Si,  S2)  be  a  relation  from  subprogram  Si  to  subprogram  S2  that  indicates 
Si  includes  an  imperative  subprogram  call  to  S2.  Let  call*{S)  represent  the  transitive 
closure  of  the  call  relation  for  an  imperative  subprogram  S.  This  is  also  termed  the  call  tree 
of  S.  Let  p*{S)  represent  the  set  of  classes  built  for  the  subprograms  in  the  call  tree  of  S. 
Let  OOD  represent  an  object-oriented  design,  let  S  represent  an  imperative  subprogram, 
and  let  P  represent  the  set  of  actual  parameters  from  S  that  are  also  formal  parameters  of 
S.  The  transformation  is  defined  as  shown  in  Figure  147.  This  transformation  moves 
each  attribute  in  Ci  that  has  already  been  built  as  an  attribute  in  C2  from  Ci  to  C2  using 
the  transformation.  The  transitive  closure  of  the  links  between  actual  parameters  and 
formal  parameters,  p*,  is  used  to  find  formal  parameters  of  subprograms  that  are  in  the 
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call  tree  of  S  that  have  been  converted  to  attributes  (using  9^)  of  the  corresponding  class. 
The  set  P'  collects  each  of  the  parameters  from  P  that  is  linked  to  an  attribute  a'  through 
H*{p)  and  6y.  Each  a'  is  an  attribute  of  a  class  in  the  set  of  classes  built  for  the  call  tree 
of  5.  The  set  P'  is  used  in  the  transformation  to  indicate  which  attributes  of  Ci  to 
move  from  class  Ci  to  class  C2.  The  transformation  is  used  because  the  attribute  a  is 
already  an  attribute  of  class  C2.  The  original  class  Ci  is  removed  from  the  design  and  the 
updated  class  is  added  to  the  design  in  order  to  produce  the  updated  design  OOD' . 

For  example,  Figure  148  shows  the  subprograms,  RADIUS,  CAPTURE,  and  BOUNCE. 
The  BOUNCE  subprogram  calls  the  RADIUS  and  CAPTURE  subprograms,  so  the  mappings 
call{BOUNCE,  RADIUS)  and  call{BOUNCE,  CAPTURE)  are  in  the  transitive  closure 
call*  (BOUNCE).  Figure  149  shows  the  classes  built  for  RADIUS,  CAPTURE,  and  BOUNCE 
before  applying  the  transformation.  Since  RADIUS  and  CAPTURE  are  called  by  BOUNCE, 
the  transformations  from  a  subprogram  to  a  class  have  already  been  done.  The  RADIUS 
subprogram  has  been  transformed  into  CLASS-1,  which  is  shown  in  the  figure.  The  CAPTURE 
subprogram  has  been  transformed  into  CLASS-2,  which  is  also  shown  in  Figure  149.  The 
transformation  of  the  subprogram  BOUNCE  is  incomplete  in  this  example,  but  the  class 
being  built  for  BOUNCE  is  shown  as  CLASS-4  in  the  figure.  Notice  at  this  point  in  the 
transformation  of  BOUNCE,  none  of  the  subprogram  calls  to  other  subprograms  have  been 
converted  to  messages.  Also  note  that  CLASS-4  currently  has  the  attributes  AXMAJ,  AXMIN, 
ANGFAC,  PROJRA,  SIGB,  RNGFAC,  RANGE,  and  other  attributes. 

Let  OOD  represent  the  design  that  includes  these  classes  built  for  BOUNCE,  CAPTURE, 
and  RADIUS.  Consider  the  following  transformation. 

T^^^iOOD,  BOUNCE,  {  AXMAJ,  AXMIN,  ANGFAC,  RANGE,  RNGFAC,  SIGB,  PROJRA  }  ) 


This  transformation  is  used  to  update  OOD  based  on  whether  the  parameters  AXMAJ, 
AXMIN,  ANGFAC,  PROJRA,  SIGB,  RNGFAC,  and  RANGE  have  been  built  as  attributes  of  any  of  the 
classes  built  for  the  call  tree  of  BOUNCE.  Note  in  Figure  148,  BOUNCE  calls  RADIUS  passing  the 
PROJRA,  SIGB,  RNGFAC,  and  RANGE  data  items  as  actual  parameters.  The  formal  parameters 
that  correspond  to  these  actual  parameters  are  the  parameters  PROJRA,  SIGB,  RNGFAC,  and 
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real  function  RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE  ) 
begin 

if  RNGFAC  >  0.0  and  RANGE  >0.0 
then  SIGABS  :=  DABS  (  SIGB); 

SLOPE  :=  SIGABS  -  PROJRA  /  RANGE; 

SPOT  :=  SIGABS  *  RANGE; 

RAD  :=  DABS  (  PROJRA  +  SLOPE  *  RNGFAC); 

RADIUS  :=  DMAXl  (  SPOT,  RAD) 
else 

RADIUS  :=  PROJRA 
endif 
end 

real  function  CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC  ) 
begin 

TILTFA  :=  DSIN  (  ANGFAC); 

RMAREA  :=  AXMAJ  ♦  AXMIN; 

EFAREA  :=  RMAREA  *  TILTFA; 

BMAREA  :=  BEAMRA  ♦  BEAMRA; 
if  EFAREA  <=  BMAREA  *  6.0d0 
then  USED  :=  EFAREA  /  BMAREA; 

CAPTURE  :=  l.OdO  -  DEXP  (  -USED) 
else  CAPTURE  :=  l.OdO 
endif 
end 


real  function  BOUNCE  (  ANGFAC,  RNGFAC,  PROJRA,  SIGB, 
RANGE,  AXMAJ,  AXMIN,  XLAMDA) 
begin 

RHOSTD  :=  0.95  *  PROJRA  *  ANGFAC; 

BEAMRA  :=  RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE); 
BOUNCE  := 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 

*  RHO  (  RHOSTD,  XLAMDA) 

end 


Figure  148  Subprograms  RADIUS,  CAPTURE,  and  BOUNCE 
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class  CLASS-1  attributes  RANGE,  RNGFAC,  SIGB,  PROJRA 
method  RADIUS  (  C-1  ) :  real  begin 

if  GET-RNGFAC  (  C-1)  >  0.0  and  GET-RANGE  (  C-1)  >0.0 
then  SIGABS  :=  DABS  (  GET-SIGB  (  C-1)); 

SLOPE  :=  SIGABS  -  GET-PRO JRA  (  C-1)  /  GET-RANGE  (  C-1); 
SPOT  :=  SIGABS  *  GET-RANGE  (  C-1); 

RAD  :=  DABS  (  GET-PRO JRA  (  C-1)  +  SLOPE  *  GET-RNGFAC  ( 
RADIUS  :=  DMAXl  (  SPOT,  RAD) 
else  RADIUS  :=  GET-PRO JRA  (  C-1)  endif 
end 

superclass  USER-OBJECT 


class  CLASS-2  attributes  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC 
method  CAPTURE  (  C-2  ):  real 
begin 

TILTFA  ;=  DSIN  (  GET- ANGFAC  (  C-2)); 

RMAREA  :=  GET- AXMAJ  (  C-2)  *  GET- AXMIN  (  C-2); 
EFAREA  :=  RMAREA  *  TILTFA; 

BMAREA  :=  GET-BEAMRA  (  C-2)  *  GET-BEAMRA  (  C-2); 
if  EFAREA  <=  BMAREA  *  6.0d0 
then  USED  :=  EFAREA  /  BMAREA; 

CAPTURE  :=  l.OdO  -  DEXP  (  -USED) 
else  CAPTURE  :=  l.OdO 
endif 
end 

superclass  USER-OBJECT 


class  CLASS-4  attributes  ANGFAC,  RNGFAC,  PROJRA,  SIGB, 
RANGE,  AXMAJ,  AXMIN,  XLAMDA 
method  BOUNCE  (  C-4  ) :  real 
begin 

RHOSTD  :=  0.95  *  GET-PRO JRA  (  C-4) 

*  GET-ANGFAC  (  C-4); 

BEAMRA  :=  RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE); 
BOUNCE  := 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 

*  RHO  (  RHOSTD,  XLAMDA) 

end 

superclass  USER-OBJECT 


Figure  149  Classes  Built  for  RADIUS,  CAPTURE,  and  BOUNCE 


C-D); 
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RANGE  declared  in  RADIUS.  This  means  the  following  mappings  are  in  the  transitive  closure 
* 

M  • 

BOUNCE::  PRO  JRA  RADIUS  ::  PRO  JRA 

BOUNCE  ::SIGB  RADIUS  ::  SIGB 

BOUNCE  ::  RNGFAC  RADIUS  ::  RNGF AC 

BOUNCE::  RANGE  RADIUS  ::  RANGE 

Also  note  that  each  of  these  formal  parameters  have  been  built  as  an  attribute  of  the 
class  built  for  RADIUS,  i.e.  CLASS- 1  shown  in  Figure  149.  All  of  this  information  means 
the  transformation  is  performed  and  the  PROJRA,  SIGB,  RNGFAC,  and  RANGE  attributes 
are  moved  from  CLASS-4  to  CLASS- 1  using  the  T\  transformation.  All  accesses  to  PROJRA, 
SIGB,  RNGFAC,  and  RANGE  in  CLASS-4  are  changed  from  accessing  instances  of  CLASS-4  to 
accessing  instances  of  CLASS-1. 

Similarly,  BOUNCE  calls  CAPTURE  passing  the  BEAMRA,  AXMAJ,  AXMIN,  and  ANGFAC  data 
items  as  actual  parameters.  The  formal  parameters  that  correspond  to  these  actual  pa¬ 
rameters  are  the  BEAMRA,  AXMAJ,  AXMIN,  and  ANGFAC  parameters.  The  following  mappings 
are  in  the  transitive  closure  pi*. 

BOUNCE::  BEAMRA  CAPTURE  ::  BEAMRA 

BOUNCE::  AXMAJ  CAPTURE  ::  AXMAJ 

BOUNCE  ::  AXMIN  CAPTURE  ::  AXMIN 

BOUNCE  ::  ANGFAC  CAPTURE  ::  ANGFAC 

Note  that  only  the  AXMAJ,  AXMIN,  and  ANGFAC  parameters  are  both  formal  and  actual 
parameters  in  BOUNCE.  In  adherence  with  PBOI  Case  1,  these  data  items  are  sent  to  the 
Tpboi  transformation,  but  the  BEAMRA  data  item  is  not.  Also  note  that  the  AXMAJ,  AXMIN, 
and  ANGFAC  parameters  have  been  built  as  attributes  of  the  class  CLASS-2.  This  means 
the  AXMAJ,  AXMIN,  and  ANGFAC  attributes  of  CLASS-4  are  moved  from  CLASS-4  to  CLASS-2 
using  the  transformation.  All  accesses  of  AXMAJ,  AXMIN,  and  ANGFAC  attributes  are 
converted  from  accessing  instances  of  CLASS-4  to  accessing  instances  of  CLASS- 1. 

Figure  150  shows  the  result  of  the  T^boi  transformation.  Note  in  the  GET-PROJRA 
message,  the  PROJRA  attribute  is  now  obtained  from  C-5,  an  instance  of  CLASS-1,  instead 
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class  CLASS-4  attributes  XLAMDA 
method  BOUNCE  (  C-4,  C-5,  C-6) :  real 

begin 

RHOSTD  :=  0.95  *  GET-PRO JRA  (  C-5) 

*  GET-ANGFAC  (  C-6); 

BEAMRA  :=  RADIUS  (  PRO JRA,  SIGB,  RNGFAC,  RANGE); 

BOUNCE  := 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 

*  RHO  (  RHOSTD,  XLAMDA) 

end 

superclass  USER-OBJECT 

Figure  150  Updated  CLASS-4  for  BOUNCE 

of  C-4,  an  instance  of  CLASS-4.  In  the  GET-ANGFAC  message,  the  ANGFAC  attribute  is  now 
obtained  from  C-6,  an  instance  of  CLASS-2,  instead  of  C-4,  an  instance  of  CLASS-4.  The 
TJ^  transformation  has  added  C-5  and  C-6  as  formal  parameters  of  the  method  BOUNCE. 

6.8.3  Formalizing  PBOI  Case  2.  The  second  case  for  converting  Category  3 
subprograms  is  that  the  formal  parameter  is  a  parameter  of  the  method  and  the  actual 
parameter  is  a  formal.  This  section  defines  the  transformation  that  formalizes  the  second 
PBOI  case  as  presented  in  Section  5.3.  The  transformation  needed  in  this  case  is  to  identify 
parameters  of  a  called  subprogram  that  are  not  attributes  and  move  them  to  parameters 
of  the  method  built  for  the  calling  subprogram.  The  transformation  is  defined  and  an 
example  is  given. 

Recall  from  Section  6.8.2,  fi*  represents  the  transitive  closure  of  the  jj,  relation, 
call*{S)  (the  call  tree  of  5)  represents  the  transitive  closure  of  the  call  relation,  and  p*{S) 
represents  the  set  of  classes  built  for  the  subprograms  in  the  call  tree  of  S.  Let  OOD 
represent  an  object-oriented  design,  let  S  represent  the  subprogram  to  be  transformed, 
and  let  P  be  the  set  of  data  items  to  consider  in  the  transformation. 

Using  these  definitions,  the  transformation  that  formalizes  PBOI  Case  2  is 
defined  as  shown  in  Figure  151.  This  transformation  checks  each  of  the  classes  built  for 
the  subprograms  in  the  call  tree  of  S.  For  any  data  item  p,  if  there  are  no  classes  that 
have  built  an  attribute  that  is  linked  to  the  parameter  p  through  the  p*  mapping,  then 
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T^f,^i{OOD,S,P)  =  OOD' where 

P'  =  {p  \  p  £  P  and  -i3  C2  €  p*{S)  such  that 
a'  =  6y{p*{p))  and  a'  G 
Cl  —  p{S)  and 

C'l  =  Ti~\00D,Ci,ey(P'))  and 
COD'  =  T+iT-{OOD,Ci),C[) 

Figure  151  The  transformation 

an  instance  of  PBOI  Case  2  has  been  found.  The  set  P'  collects  these  data  items  so  they 
can  be  changed  from  attributes  to  parameters.  All  of  the  data  items  in  P'  are  changed 
from  attributes  of  the  class  built  for  S,  i.e.  Ci,  into  parameters  of  the  methods  of  Ci 
using  the  transformation.  Once  p  is  converted  to  a  GOM  variable  using  the  6y 

transformation,  it  is  appropriate  to  move  the  variable  from  an  attribute  to  a  parameter 
because  both  attributes  and  parameters  are  variables  in  the  object  paradigm.  For  example, 
Figure  152  shows  the  subprograms  CAPTURE  and  BOUNCE  (whose  statements  do  not  match 
those  shown  in  Figure  148).  The  BOUNCE  subprogram  calls  the  CAPTURE  subprogram, 
so  the  mapping  call  {BOUNCE,  CAPTURE)  is  one  of  the  mappings  in  the  transitive 
closure  call*  (BOUNCE).  Figure  153  shows  the  classes  built  for  CAPTURE  and  BOUNCE. 
The  subprogram  CAPTURE  has  been  completely  transformed  since  it  is  called  by  BOUNCE. 
CLASS-4  in  the  figure  is  the  incomplete  class  being  built  for  BOUNCE.  At  this  point  in  the 
transformation,  none  of  the  subprogram  calls  have  been  converted  to  messages  in  CLASS-4. 

Let  OOD  represent  the  design  that  includes  the  classes  built  for  BOUNCE  and  CAPTURE. 
Consider  the  transformation 

Tl^„i{OOD,  BOUNCE,  {  AXMAJ,  AXMIN,  ANGFAC  }  ) 

This  transformation  is  used  to  update  OOD  based  on  whether  the  parameters  AXMAJ, 
AXMIN,  or  ANGFAC  have  been  built  as  attributes  of  any  of  the  classes  in  the  call  tree  of 
BOUNCE.  Note  in  the  figure  that  even  though  BOUNCE  calls  the  other  subprograms  RADIUS  and 
RHO,  the  AXMAJ,  AXMIN,  and  ANGFAC  data  items  are  only  passed  to  the  CAPTURE  subprogram. 
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real  function  CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC  ) 
begin 

TILTFA  :=  DSIN  (  ANGFAC); 

RMAREA  :=  AXMAJ  *  AXMIN; 

EFAREA  :=  RMAREA  *  TILTFA; 

BMAREA  :=  BEAMRA  *  BEAMRA; 
if  EFAREA  <=  BMAREA  *  6.0d0 
then  USED  :=  EFAREA  /  BMAREA; 

CAPTURE  :=  l.OdO  -  DEXP  (  -USED) 
else  CAPTURE  :=  l.OdO 
endif 
end 


real  function  BOUNCE  (  ANGFAC,  RNGFAC,  PROJRA,  SIGB, 
RANGE,  AXMAJ,  AXMIN,  XLAMDA) 
begin 

RHOSTD  ;=  0.95  *  ANGFAC; 

BEAMRA  :=  RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE); 
BOUNCE  := 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 

*  RHO  (  RHOSTD,  XLAMDA) 

end 


Figure  152  Subprograms  CAPTURE  and  BOUNCE 

This  means,  for  this  example,  the  only  possible  class  that  could  have  attributes  that  are 
linked  to  these  data  items  through  the  fx*  relation  is  the  class  built  for  CAPTURE.  As  is  seen 
in  Figure  152,  the  actual  parameters  AXMAJ,  AXMIN,  and  ANGFAC  are  linked  to  the  formal 
parameters  AXMAJ,  AXMIN,  and  ANGFAC,  respectively,  declared  in  the  CAPTURE  subprogram. 
This  means  the  following  mappings  are  in  the  transitive  closure  /z*. 

BOUNCE  ::  AXMAJ  -C  C APTU RE  ::  AX M AJ 
BOUNCE  ::  AXMIN  CAPTURE  ::  AXMIN 

BOUNCE  ::  ANGFAC  CAPTURE  ::  ANGFAC 

As  shown  in  Figure  153,  the  AXMAJ  and  AXMIN  data  items  have  been  built  as  attributes 
of  the  class  CLASS-2,  but  the  ANGFAC  data  item  has  not  been  built  as  an  attribute.  The 
ANGFAC  data  item  is  a  parameter  of  the  method  that  implements  CAPTURE.  This  means 
in  the  transformation,  the  only  data  item  in  the  set  P'  is  ANGFAC.  This  attribute  is 
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class  CLASS-2  attributes  BEAMRA,  AXMAJ,  AXMIN 
method  CAPTURE  (  C-2,  ANGFAC  ):  real 
begin 

TILTFA  :=  DSIN  (  ANGFAC); 

RMAREA  :=  GET-AXMAJ  (  C-2)  *  GET-AXMIN  (  C-2); 
EFAREA  :=  RMAREA  *  TILTFA; 

BMAREA  :=  GET-BEAMRA  (  C-2)  *  GET-BEAMRA  (  C-2); 
if  EFAREA  <=  BMAREA  *  6.0d0 
then  USED  :=  EFAREA  /  BMAREA; 

CAPTURE  :=  l.OdO  -  DEXP  (  -USED) 
else  CAPTURE  :=  l.OdO 
endif 
end 

superclass  USER-OBJECT 


class  CLASS-4  attributes  ANGFAC,  RNGFAC,  PROJRA,  SIGB, 
RANGE,  AXMAJ,  AXMIN,  XLAMDA 
method  BOUNCE  (  C-4  ) :  real 
begin 

RHOSTD  :=  0.95  *  GET-ANGFAC  (  C-4); 

BEAMRA  :=  RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE); 
BOUNCE  := 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 

*  RHO  (  RHOSTD,  XLAMDA) 

end 

superclass  USER-OBJECT 


Figure  153  Classes  Built  for  CAPTURE  and  BOUNCE 

removed  from  CLASS-4  and  added  as  a  parameter  to  the  method  that  implements  BOUNCE 
by  using  the  ^  transformation.  Figure  154  shows  the  result  of  the  transformation. 
The  ANGFAC  data  item  has  been  changed  from  an  attribute  of  CLASS-4  to  a  parameter 
of  the  BOUNCE  method.  The  message  GET-ANGFAC  (  C-6),  which  accesses  the  attribute 
ANGFAC,  has  been  changed  to  access  the  parameter  ANGFAC.  This  updated  class  replaces 
the  original  class  in  the  design  OOD  to  produce  the  updated  design  OOD' . 

6.8.4  Formalizing  PBOI  Case  3.  The  third  case  for  converting  Category  3  sub¬ 
programs  is  that  the  formal  parameter  is  an  attribute  and  the  actual  parameter  is  not  a 
formal.  This  section  defines  the  transformation  that  formalizes  the  third  case  for  PBOI 
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class  CLASS-4  attributes  RNGFAC,  PROJRA,  SIGB, 

RANGE,  AXMAJ,  AXMIN,  XLAMDA 
method  BOUNCE  (  C-4,  ANGFAC  ):  real 

begin 

RHOSTD  :=  0.95  *  ANGFAC; 

BEAMRA  :=  RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE); 

BOUNCE  := 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 

*  RHO  (  RHOSTD,  XLAMDA) 

end 

superclass  USER-OBJECT 

Figure  154  Updated  Class  for  BOUNCE 

as  described  in  Section  5.3.  This  case  identifies  parameters  from  the  called  subprogram 
that  have  been  built  as  attributes  of  a  class  but  are  not  formal  parameters  of  the  calling 
subprogram.  The  transformation  needed  for  this  case  is  to  move  the  identified  data  items 
from  attributes  to  parameters.  The  transformation  for  case  three  is  defined  below  followed 
by  an  example. 

As  defined  in  Section  6.8.2,  /x*  represents  the  transitive  closure  of  the  /x  relation, 
call*{Si)  (the  call  tree  of  5i)  represents  the  transitive  closure  of  the  call  relation,  and  p*{Si) 
represents  the  set  of  classes  built  for  the  subprograms  in  the  call  tree  of  Si.  Let  OOD 
represent  an  object-oriented  design,  let  Si  represent  the  subprogram  being  transformed, 
and  let  P  be  the  set  of  data  items  being  considered  in  the  transformation.  Let  p*{P') 
represent  the  set  of  data  items  resulting  from  the  application  of  p*  to  the  data  items  in  P'. 

Using  these  definitions,  the  transformation  that  formalizes  PBOI  Case  3  is  defined 
as  shown  in  Figure  155.  This  transformation  is  fundamentally  different  from  the  transfor¬ 
mations  that  formalize  PBOI  Case  1  and  PBOI  Case  2.  The  changes  that  were  made  to 
the  design  OOD  in  Case  1  and  Case  2  were  made  only  to  the  class  that  was  built  for  the 
subprogram  S.  In  the  transformation  for  Case  3,  no  change  is  required  for  the  class  built 
for  Si,  but  other  classes  in  the  call  tree  of  may  be  changed.  If  a  class  is  found  in  p*{Si) 
that  has  an  attribute  that  can  be  linked  to  a  parameter  p  through  0^  and  the  /x*  relation, 
then  each  of  the  classes  built  for  the  subprograms  that  include  p  as  a  formal  parameter  is 
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TXi{OOD,S^,P)  =  OOi)' where 
Cl  =  p{S\)  and 

P'  =  {p  I  p  G  P  and  3  C3  €  p*(5'i)  such  that 
b'  =  ^u(p*(p))  fflwd  fe'  G  $03} 

V  C2  G  OOP 

52  =  p"^(C2)  and 

S2  =  <  ids2  )  Pins2  ’  •^o“ts2  ’  ^  and 

P forms^  ~  ^ins2  ®  ^outs^ 

A  =  {a^  I  p'  G  P'  and  a'  =  p*{p')  and  a'  G  Pforms2} 

C'2  =  Ti'\oOD,C2,0v{A))  and 
G  OOP'  A  C2  ^  OOP' 

Figure  155  The  Tpj,oj  transformation 

transformed.  The  set  P'  collects  any  such  parameters  from  P.  All  the  classes  in  the  design 
OOP  are  examined  to  see  if  they  require  an  update.  The  subprogram  that  is  associated 
with  each  class  C2  is  determined  (by  using  p~^)  and  the  formal  parameters  of  this  subpro¬ 
gram  S2  are  examined.  If  S2  has  a  formal  parameter  that  can  be  linked  to  p'  G  P'  by  the 
p*(p')  transitive  closure,  then  the  transformation  must  ensure  this  parameter  has  not 
been  built  as  an  attribute.  The  ^  transformation  is  used  to  transform  the  attributes 
associated  with  such  parameters  into  parameters  of  the  methods  of  C2. 

Let  the  term  call  path  represent  a  mapping  in  the  call* (Si)  transitive  closure  such 
that  call(Si,S2)  indicates  a  call  path  from  5i  to  S2.  Since  the  call*{Si)  relation  is  a 
transitive  closure,  there  may  be  multiple  call  mappings  in  call* (Si)  of  the  form  call(Si,  Sn) 
and  call(Sn,  S^)  and  call(Sm,  S2)  that  were  used  to  build  the  mapping  call(Si,S2)-  All 
these  subprograms,  5i,  S^,  Sm,  and  S2,  are  considered  to  be  in  the  call  path  from  Si 
to  52.  Let  S3  =  p~^(Ci),  where  Ci  is  the  class  that  has  built  the  parameter  p  as  an 
attribute.  The  transformation  is  built  specifically  to  update  all  the  classes  that  have 
been  built  for  the  subprograms  in  the  call  path  from  5i  and  53.  This  is  a  critical  part  of 
the  transformation  because  each  method  that  implements  the  subprograms  in  the  call  path 
from  5i  to  S3  must  now  access  p  as  a  parameter  instead  of  as  an  attribute  of  some  object. 
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This  is  why  each  of  the  classes  in  the  design  OOD  is  checked  and  the  transitive 

closure  is  used  to  identify  such  parameters. 

In  some  classes,  the  data  item  a'  will  not  be  an  attribute  of  the  class  C2.  The 
transformation  will  make  the  correct  transformation  because  set  difference  is  used  by  the 
^  transformation  to  remove  a'  from  the  set  of  attributes  for  the  class.  Whether  or  not 
a'  is  in  the  set  of  attributes,  the  result  is  a  set  of  attributes  that  does  not  contain  a' .  In 
some  cases,  the  data  item  a'  will  already  be  a  parameter  of  the  methods  of  a  class.  In  this 
case  the  transformation  will  make  the  correct  transformation  because  the  ©  operation 
(defined  in  Section  3.24)  is  used  to  add  a!  to  the  sequence  of  formal  parameters  of  each 
method.  The  ©  operation  adds  a  parameter  to  a  sequence  of  parameters  without  allowing 
duplicates.  Whether  or  not  a'  is  originally  in  the  sequence  of  parameters  for  the  method, 
the  result  is  a  sequence  of  parameters  that  now  includes  a' . 

As  an  example.  Figure  156  shows  the  subprograms  RHO,  BOUNCE,  and  RELAY-PHASE. 
These  subprograms  have  been  altered  from  previous  examples.  The  RELAY-PHASE  subpro¬ 
gram  calls  the  BOUNCE  subprogram,  so  the  call{RE  LAY -PHASE,  BOUNCE)  mapping  is 
included  in  the  transitive  closure  call* (RELAY-PHASE).  The  BOUNCE  subprogram  calls 
the  RHO  subprogram,  so  the  call{BOUNCE,RHO)  and  the  call{RELAY-PHASE,  RHO) 
mappings  are  also  included  in  the  transitive  closure  call*  (RE LAY -PH AS E).  In  this  ex¬ 
ample,  the  call  path  from  RELAY-PHASE  to  RHO  includes  the  subprograms  RHO,  BOUNCE,  and 
RELAY-PHASE. 

The  classes  built  for  these  subprograms  are  shown  in  Figure  157.  The  subprograms 
BOUNCE  and  RHO  have  already  been  transformed  since  they  are  called  by  RELAY-PHASE. 
The  incomplete  class  being  built  for  RELAY-PHASE  is  shown  in  the  figure  as  CLASS-5.  The 
subprogram  call  to  BOUNCE  has  not  yet  been  converted  to  a  message. 

Let  OOD  represent  the  design  that  includes  these  three  classes.  Consider  the  trans¬ 
formation 


T^f,^i{OOD,  RELAY-PHASE,  {  RHOSTD,  XLAMDA  }  ) 
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real  function  RHO  (  RHOSTD,  LAMBDA) 
begin 

RHO  :=  RHOSTD  *  LAMBDA 
end 

real  function  BOUNCE  (  ANGFAC,  RNGFAC,  PROJRA,  SIGB, 
RANGE,  AXMAJ,  AXMIN,  RHOSTD,  XLAMDA) 
begin 

BEAMRA  ;=  RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE); 
BOUNCE  := 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 

*  RHO  (  RHOSTD,  XLAMDA) 

end 


procedure  RELAY-PHASE  (  DIAM,  UPLFAC,  RNGFAC,  ZENITH,  SIGB, 
AXMAJ,  AXMIN,  PHASE  ) 


begin 
PHASE  : 

=  1; 

RHOSTD 

:=  0.95; 

ANGFAC 

:=  UPLFAC  *  3.14159; 

PROJRA 

:=  DIAM  /  2; 

RANGE  : 

=  ZENITH  *  PROJRA  *  ANGFAC; 

XLAMDA 

:=  0.625; 

PHASE  : 

=  BOUNCE  (  ANGFAC,  RNGFAC,  PROJRA, 

RANGE 

,  AXMAJ,  AXMIN,  RHOSTD,  XLAMDA) 

end 

Figure  156  Subprograms  RHO,  BOUNCE,  and  RELAY-PHASE 
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class  CLASS-3  attributes  RHOSTD,  LAMBDA 
method  RHO  (  C-3  ) :  real 
begin 

RHO  :=  GET-RHOSTD  (  C-3)  *  GET-LAMBDA  (  C-3) 
end 

superclass  USER-OBJECT 


class  CLASS-4  attributes 
method  BOUNCE  (  C-4,  C-5,  C-6,  C-7  ):  real 
begin 

BEAMRA  :=  RADIUS  (  C-5); 

BOUNCE  :=  CAPTURE  (  C-6,  BEAMRA)  *  RHO  (  C-7) 
end 

superclass  USER-OBJECT 


class  CLASS-5  attributes  DIAM,  UPLFAC,  RNGFAC,  ZENITH,  SIGB, 
AXMAJ,  AXMIN,  PHASE 
method  RELAY-PHASE  (  C-8  ) 
begin 

SET-PHASE  (  C-8,  1); 

RHOSTD  :=  0.95; 

ANGFAC  :=  GET-UPLFAC  (  C-8)  *  3.14159; 

PROJRA  :=  GET-DIAM  (  C-8)  /  2; 

RANGE  :=  GET-ZENITH  (  C-8)  *  PROJRA  *  ANGFAC; 

XLAMDA  :=  0.625; 

SET-PHASE  (  C-8,  BOUNCE  (  ANGFAC,  RNGFAC,  PROJRA,  SIGB, 
RANGE,  AXMAJ,  AXMIN,  RHOSTD,  XLAMDA)) 
end 

superclass  USER-OBJECT 


Figure  157  Classes  Built  for  RHO,  BOUNCE,  and  RELAY-PHASE 
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This  transformation  updates  the  OOD  to  comply  with  PBOI  Case  3  since  the  data  items 
RHOSTD  and  XLAMDA  are  actual  parameters  but  are  not  formal  parameters  in  the  subpro¬ 
gram  RELAY-PHASE.  As  shown  in  the  figure,  the  RELAY-PHASE  subprogram  calls  the  BOUNCE 
subprogram  passing  RHOSTD  and  XLAMDA  as  actual  parameters.  The  corresponding  formal 
parameters  in  BOUNCE  are  the  RHOSTD  and  XLAMDA  formal  parameters.  This  means  the 
following  mappings  are  in  the  transitive  closure  jx*. 

RELAY-PHASE::  RHOSTD  BOUNCE  ::  RHOSTD 

RELAY-PHASE::  XLAMDA  BOUNCE  ::  XLAMDA 


The  subprogram  BOUNCE  calls  the  subprogram  RHO  passing  the  RHOSTD  and  XLAMDA 
parameters  as  actual  parameters.  The  formal  parameters  that  correspond  to  these  actual 
parameters  are  the  RHOSTD  and  LAMBDA  formal  parameters  declared  in  RHO.  This  means  the 
following  mappings  are  in  the  transitive  closure  fi*. 


BOUNCE  ::  RHOSTD 
BOUNCE ::  XLAMDA 
RELAY-PHASE::  RHOSTD 
RELAY-PHASE::  XLAMDA 


At 

At* 

At* 

At* 


RHO  ::  RHOSTD 
RHO  ::  LAMBDA 
RHO  ::  RHOSTD 
RHO  ::  LAMBDA 


Notice  in  Figure  157,  the  class  CLASS-3  built  for  RHO  has  built  the  RHOSTD  and 
LAMBDA  data  items  as  attributes  of  the  class.  This  means  a  class  exists  in  the  call  tree  for 
RELAY-PHASE  that  includes  an  attribute  that  can  be  linked  to  the  RHOSTD  and  XLAMDA  data 
items  in  RELAY-PHASE.  Both  RHOSTD  and  XLAMDA  are  collected  into  the  set  P'  for  further 
evaluation.  The  transformation  continues  by  examining  each  class  in  the  design  OOD 
to  see  if  it  needs  to  be  transformed. 

For  this  example,  OOD  includes  the  three  classes  CLASS-3,  CLASS-4,  and  CLASS-5. 
For  CLASS-5,  the  transformation  uses  the  p~^  mapping  to  find  the  subprogram 
RELAY-PHASE.  The  set  A  for  this  subprogram  is  empty  since,  in  this  example,  each  p' 
is  a  variable  defined  in  RELAY-PHASE  and  there  are  no  mappings  in  p*  that  map  data  items 
in  RELAY-PHASE  to  other  data  items  in  RELAY-PHASE.  The  only  way  for  those  mappings  to 
be  in  p*  would  be  from  a  recursive  call  to  RELAY-PHASE,  and  recursion  is  not  allowed  in  the 
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C_1 

GOM.  This  means  the  empty  set  A  is  passed  to  the  transformation  and  no  change  is 
made  to  CLASS-5,  as  required. 

For  CLASS-4,  the  subprogram  associated  with  this  class  is  the  BOUNCE  subprogram. 
The  set  A  for  BOUNCE  is  {  RHOSTD ,  XLAMDA  }  since  these  data  items  have  mappings  in  /i*  to 
the  RHOSTD  and  XLAMDA  data  items,  respectively,  in  RELAY-PHASE.  The  ^  transformation 
is  passed  these  data  items  which  ensures  RHOSTD  and  XLAMDA  aren’t  attributes  of  CLASS-4, 
but  are  parameters  of  the  methods  of  CLASS-4. 

class  CLASS-4  attributes 

method  BOUNCE  (  C-4,  C-5,  C-6,  C-7,  RHOSTD,  XLAMDA  ):  real 
begin 

BEAMRA  :=  RADIUS  (  C-5); 

BOUNCE  :=  CAPTURE  (  C-6,  BEAMRA) 

*  RHO  (  C-7,  RHOSTD,  XLAMDA) 
end 

superclass  USER-OBJECT 

Figure  158  Updated  Class  for  BOUNCE 

Figure  158  shows  the  result  of  this  transformation.  The  RHOSTD  and  XLAMDA  data 
items  are  not  attributes  of  CLASS-4,  but  are  formal  parameters  of  the  method  BOUNCE  and 
actual  parameters  in  the  message  RHO. 

For  CLASS-3,  the  subprogram  associated  with  this  class  is  the  RHO  subprogram.  The 
set  A  for  RHO  is  {  RHOSTD ,  LAMBDA  }  since  these  data  items  have  mappings  in  /i*  to  the 
RHOSTD  and  XLAMDA  data  items,  respectively,  in  RELAY-PHASE.  The  ^  transformation 
is  passed  {  RHOSTD,  LAMBDA  }  which  ensures  RHOSTD  and  LAMBDA  are  not  attributes  of 
CLASS-3,  but  are  parameters  of  the  methods  of  CLASS-3. 

Figure  159  shows  the  result  of  the  ^  transformation  on  CLASS-3.  The  RHOSTD 
and  LAMBDA  data  items  are  now  parameters  of  the  RHO  method  instead  of  attributes  of  the 
CLASS-3  class.  The  three  updated  classes  are  included  in  the  updated  design  returned 
from  the  transformation. 
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class  CLASS-3  attributes 
method  RHO  (  C-3,  RHOSTD,  LAMBDA  ):  real 
begin 

RHO  :=  RHOSTD  *  LAMBDA 
end 

superclass  USER-OBJECT 

Figure  159  Updated  Class  for  RHO 

TX,{00D,S,P)  =  OOD' where 

P'  =  {p  I  p  €  P  and  -i3  Ci  €  p*{S)  such  that 
O''  =  ond  a'  G  $Ci}  ond 

OOD'  =  OOD 

Figure  160  The  transformation 

6.8,5  Formalizing  PBOI  Case  4-  The  fourth  case  for  converting  Category  3 
subprograms  is  that  the  formal  parameter  is  a  parameter  of  the  method  and  the  actual  pa¬ 
rameter  is  not  a  formal.  This  section  defines  the  formal  transformation  that  formalizes  the 
fourth  case  of  the  PBOI  method,  as  defined  in  Section  5.3.  This  case  identifies  parameters 
of  the  called  subprogram  that  are  not  attributes  of  a  class  and  are  not  formal  parameters 
of  the  calling  subprogram.  There  is  no  change  to  the  object-oriented  design  required  for 
this  case.  The  transformation  is  defined  below  and  an  example  is  given  at  the  end  of  this 
section. 

As  defined  in  Section  6.8.2,  p*  represents  the  transitive  closure  of  the  p  relation, 
call*{S)  (the  call  tree  of  5)  represents  the  transitive  closure  of  the  call  relation,  and  p*{S) 
represents  the  set  of  classes  built  for  the  subprograms  in  the  call  tree  of  S.  The  formal 
transformation  is  defined  in  Figure  160.  This  transformation  checks  each  class  in  the  set 
of  classes  built  for  the  subprograms  in  the  call  tree  of  5.  If  none  of  the  classes  have  an 
attribute  that  can  be  linked  through  the  p*  relation  to  the  parameter  p,  then  there  is  no 
change  required  in  the  design. 

For  example,  consider  the  RADIUS  and  BOUNCE  subprograms  shown  in  Figure  161. 
These  subprograms  have  been  changed  slightly  to  illustrate  PBOI  Case  4.  The  PROJRA 
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real  function  RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE  ) 
begin 

if  RNGFAC  >  0.0  and  RANGE  >0.0 
then  SIGABS  :=  DABS  (  SIGB); 

SLOPE  :=  SIGABS  -  PROJRA  /  RANGE; 

SPOT  :=  SIGABS  *  RANGE; 

RAD  :=  DABS  (  PROJRA  +  SLOPE  ♦  RNGFAC); 

RADIUS  :=  DMAXl  (  SPOT,  RAD) 
else 

RADIUS  :=  PROJRA 
endif 
end 


real  ftinction  BOUNCE  (  ANGFAC,  RNGFAC,  SIGB, 
RANGE,  AXMAJ,  AXMIN,  XLAMDA) 


begin 

PROJRA 

:=  XLAMDA 

*  3.14159; 

RHOSTD 

:=  0.95; 

BEAMRA 

:=  RADIUS 

(  PROJRA,  SIGB,  RNGFAC,  RANGE); 

BOUNCE 

;  = 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 
*  RHO  (  RHOSTD,  XLAMDA) 

end 


Figure  161  Subprograms  RADIUS  and  BOUNCE 
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class  CLASS-1  attributes  RANGE,  RNGFAC,  SIGB 
method  RADIUS  (  C-1,  PROJRA  ):  real  begin 

if  GET-RNGFAC  (  C-1)  >  0.0  and  GET-RANGE  (  C-1)  >0.0 
then  SIGABS  :=  DABS  (  GET-SIGB  (  C-1)); 

SLOPE  :=  SIGABS  -  PROJRA  /  GET-RANGE  (  C-1); 

SPOT  :=  SIGABS  *  GET-RANGE  (  C-1); 

RAD  :=  DABS  (  PROJRA  +  SLOPE  *  GET-RNGFAC  (  C-1)); 

RADIUS  :=  DMAXl  (  SPOT,  RAD) 
else 

RADIUS  :=  PROJRA 
endif 
end 

superclass  USER-OBJECT 


class  CLASS-4  attributes  ANGFAC,  RNGFAC,  SIGB, 

RANGE,  AXMAJ,  AXMIN,  XLAMDA 
method  BOUNCE  (  C-4  ) :  real 
begin 

PROJRA  :=  XLAMDA  *  3.14159; 

RHOSTD  :=  0.95; 

BEAMRA  :=  RADIUS  (  PROJRA,  SIGB,  RNGFAC,  RANGE); 
BOUNCE  ;= 

CAPTURE  (  BEAMRA,  AXMAJ,  AXMIN,  ANGFAC) 

*  RHO  (  RHOSTD,  XLAMDA) 

end 

superclass  USER-OBJECT 


Figure  162  Classes  Built  for  RADIUS  and  BOUNCE 

data  item  is  now  a  local  variable  of  the  BOUNCE  subprogram.  In  the  example,  the  BOUNCE 
subprogram  calls  the  RADIUS  subprogram,  so  the  call  {BOUNCE,  RADIUS)  mapping  is 
included  in  the  transitive  closure  call*  (BOUNCE).  Figure  162  shows  the  classes  that 
are  built  for  the  RADIUS  and  BOUNCE  subprograms.  The  RADIUS  subprogram  has  been 
completely  transformed  into  class  CLASS-1  since  it  is  called  by  BOUNCE.  This  class  is  different 
than  the  other  example  transformation  of  RADIUS  (see  Figure  149).  In  Figure  162,  the 
PROJRA  data  item  has  not  been  built  as  an  attribute  of  the  class  built  for  RADIUS.  The 
incomplete  class  being  built  for  BOUNCE  is  CLASS-4  as  shown  in  the  figure. 
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Let  OOD  represent  the  design  developed  so  far  that  includes  these  two  classes.  Con¬ 
sider  the  transformation 


Tp\„i(OOL>,  BOUNCE,  PROJRA) 

This  transformation  checks  all  the  classes  built  for  the  subprograms  in  the  call  tree  of 
BOUNCE  to  see  if  any  of  the  classes  have  an  attribute  that  can  be  linked  through  the  fi* 
relation  to  the  PROJRA  data  item.  The  BOUNCE  subprogram  calls  the  RADIUS  subprogram 
passing  in  PROJRA  as  an  actual  parameter.  The  formal  parameter  that  corresponds  to 
this  actual  parameter  is  the  PROJRA  formal  parameter  declared  in  RADIUS.  This  means  the 
following  mapping  is  in  the  transitive  closure  n*{BOUNCE  ::  PROJRA). 

BOUNCE::  PROJRA  RADIUS  ::  PROJRA 

The  PROJRA  data  item  in  RADIUS  has  not  been  built  as  an  attribute.  Since  in  the  call 
tree  of  BOUNCE  the  PROJRA  data  item  is  passed  only  to  the  RADIUS  subprogram,  it  can  be 
concluded  that  there  is  not  a  class  in  the  call  tree  of  BOUNCE  that  has  built  PROJRA  as  an 
attribute. 

6.8.6  Formalizing  PBOI.  This  section  defines  the  high-level  transformation  com¬ 
bining  the  four  transformations  that  formalize  the  four  PBOI  cases.  The  formal  transfor¬ 
mation  is  defined  and  an  example  is  given. 

Let  OOD  represent  an  object-oriented  design,  let  S  represent  the  subprogram  being 
transformed.  Let  Csuhs  be  the  set  of  imperative  subprogram  calls  in  S.  Let  P*^^  be  the 
sequence  collecting  all  the  actual  parameters  from  all  the  subprogram  calls  in  S,  such  that 
duplicate  parameters  are  not  included  and  the  order  of  the  sequence  is  arbitrary.  Let 
be  the  high-level  transformation  that  determines  which  of  the  four  PBOI  transformations 
to  apply.  The  Tpijoi  transformation  is  defined  as  shown  in  Figure  163.  This  transformation 
is  used  to  update  the  object-oriented  design  developed  so  far  by  applying  the  four  PBOI 
transformations  defined  in  the  previous  sections.  This  high-level  transformation  examines 
the  subprogram  calls  that  the  input  subprogram  S  makes  and  determines  which  PBOI  for¬ 
mal  transformation  to  apply  for  each  actual  parameter  p  of  the  call.  The  reduce  operation 
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TpboiiOOD,  S)  =  OODi  where 

S  =  <  ids  5  Pin.)  Pout)  Pret^  Ploc^  ^5  ^  ClTld 

Pform  ~  Pin  ©  Pout  tlTld 

Pact  =  reduce{®,  [Pacin  1  ^  ^  C^subs 

I  —  -K  >  ])  (iTtd 

OODi  -  Tpf,gi{OOD,S,  Pform  n  P*ci) 

OOD2  =  Tpf,gi{OODi,S,Pform  n  P*ot)  and 
OODz  =  Tpf,^{OOD2,  S,  Pform  -  Pact) 

OODi  =  Tp^oiiOODz)S,  Pform  “  Pact) 

Figure  163  The  Tpboi  transformation 

is  used  to  apply  the  ©  operator  in  order  to  combine  the  sequences  of  actual  parameters. 
Each  actual  parameter  is  checked  to  see  if  it  is  also  a  formal  parameter  of  the  calling  sub¬ 
program  S.  If  an  actual  parameter  is  also  a  formal  parameter,  then  either  PBOI  Case  1  or 
PBOI  Case  2  applies.  If  the  actual  parameter  is  not  a  formal  parameter  then  either  PBOI 
Case  3  or  PBOI  Case  4  applies. 

6.9  Transforming  Subprogram  Calls 

This  section  defines  the  formal  transformations  used  to  convert  imperative  subpro¬ 
gram  calls  to  object-oriented  messages.  These  transformations  are  used  when  converting 
Category  3  subprograms.  Let  Vm  be  the  transformation  that  converts  subprogram  calls  to 
messages.  In  order  to  transform  a  subprogram  call  I  into  a  message  m,  it  is  assumed  that 
the  method  to  be  invoked  by  m  already  exists  in  some  class  C.  Let  instance{c,  C)  represent 
whether  or  not  an  object  c  is  an  instance  of  class  C.  The  Vm  transformation  is  defined  as 
shown  in  Figure  164.  This  transformation  ensures  that  each  of  the  actual  parameters  in 
the  subprogram  call  I  is  either  an  attribute  of  the  target  object  c,  an  attribute  of  one  of 
the  other  objects  passed  to  the  method,  or  a  formal  parameter  of  the  method.  The  target 
object,  each  of  the  other  objects  required,  and  the  formal  parameters  are  built  as  actual 
parameters  of  the  message  m. 
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1)^(5,  Z)  =  m  where 

I  =  <  ids^,Pact  >  and 
(3  C2  €  p*{S)  such  that 

C2  =  <  idc2 ,  ^C2  ?  ^C2  >  ^0  >  and 

^C2  ~  {.'^^dSn,T2.,Qobj2tQform2tQTet2iQloc2i^C2  )and 
instance(c,  C2)  and 
V  p  e  Pact 

[a'  =  d^{fi*(p))  and  a'  G  #(72]  ar 
[3  C3  G  p*{S)  such  that 

C3  =  <  i(Zc3»^C3  5^C3>-^0  >  and 
b'  —  0vip*ip))  and  b'  G  ^Cs  and 
instance{q,Cz)  and 
Q  €  Qobj2  and  q  G  Qobj  and  q  G  or 
[d'  =  9v{p*ip))  and  d'  G  Qform2  and 
P'  =  0v{p)  andp'  G  Q'form]  O'nd 
Qact  ~  [*']  ®  Qobj  ®  Q form  and 

m  =  <  ids^,Qact  > 

Figure  164  The  Vm  transformation 
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The  Ve  transformation,  shown  in  Figure  165,  is  defined  to  use  the  Vm  transformation 
in  order  to  transform  each  function  call  in  an  imperative  expression.  This  transformation 
uses  the  formal  definition  for  each  imperative  expression  in  its  definition. 

In  order  to  transform  subprogram  calls  in  each  statement  and  expression,  the  v 
transformation  has  been  defined  as  shown  in  Figure  166.  This  transformation  uses  the 
formal  definitions  of  imperative  statements  in  its  definition.  Recall  that  pos{s,  'F)  indicates 
the  ordinal  position  of  a  statement,  s,  in  the  sequence,  This  transformation  takes  as 
input  a  sequence  of  imperative  statements  and  object-oriented  statements.  The  resulting 
sequence  is  a  sequence  of  object-oriented  statements  where  the  subprogram  calls  from  the 
imperative  statements  and  expressions  have  been  replaced  by  messages. 

Let  be  the  formal  transformation  that  takes  an  object-oriented  design,  a  subpro¬ 
gram,  and  a  class  and  replaces  all  the  subprogram  calls  in  the  statements  of  the  class’ 
method  with  messages.  This  transformation  is  defined  as  follows. 

T^{OOD,S,C)  =  OOP' where 

Oc  ~  '^dg,T,Q0l,j,  Q foTTfii  Qret^  Qlocy^ o 

=  v(S,  ^g)  and 

0(7  ~  ‘^dg,  T,Q gif j,  Q fgrui,  Q j-gi,  Qlgg,^ g  >}  OTirf 

C'  =  <  Aq  >  and 

OOD'  =  T+(T-(00P,0),0') 

Each  subprogram  call  in  is  replaced  by  corresponding  message  by  using  the  v 
transformation.  These  updated  statements  are  used  to  update  the  method  in  Q'q  in  the 
updated  class  O'.  This  class  replaces  the  class  C  in  the  design  and  the  updated  design  is 
returned  as  the  result  of  the  transformation. 

For  example.  Figure  167  shows  the  class  CLASS-3  containing  the  method  RHO.  The 
original  imperative  subprogram  call  to  the  subprogram  RHO  is  given  below. 

RHO  (  RHOSTD,  XLAMDA,  ANGFAC) 

Let  C-7  be  an  instance  of  CLASS-3.  The  subprogram  call  is  transformed  into  the  following 
message. 
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Ve(S,e)  =  e' where 

e  =  <  ids^jPact  >=^  e'  =  VmiSje)  and 
gom-variable(e)  =j>  e'  =  e  and 
e  =  <  GET-a,  [c]  >=>  =  e  and 

gom-literal-boolean(e)  =>  e'  =  e  and 
gom-literal-integer(e)  e'  =  e  and 
gom-literal-real(e)  ^  e'  =  e  and 
goin-literal-string(e)  e'  =  e  and 

e  =  <  ei,  +,62  >  e'  =  <  We(S,  ei),  +,fe('S',  £2)  >  and 
6  =  <  ei,  and,  £2  >  =+  e'  =  <Ve{S,e\),  and, ne(5,  £2)  >  and 
6  =  <  £1,  &,  £2  >  e'  =  <  Ve{S,ei),  &i,Ve{S,  62)  >  and 
e  =  <  ei,  /,£2  >  ^  e'  =  <  t;e(S,ei),  l,Ve{S,  62)  >  and 

£  =  <  £1,  =,£2  >  e'  =  <  Ve{S,ei),  =,Vg{S,e2)  >  and 

£  =  <  ei,  **,£2  >  e'  =  <Ve{S,ei),  **,Ve{S,e2)  >  and 

£  =  <  d,  >=,  £2  >  =»  e'  =  <  Ve{S,ei),>=,Ve{S,e2)  >  and 

e  =<£i,>,£2>=»  e'  =  <  ne(5,  £i),>,ne(5,  £2)  >  and 
e  =  <  ei,  <=,£2  >  =>  e'  =  <  Ve{S,ei),<=,Ve{S,e2)  >  and 
e  =<£i,<,£2>=>  £'  =  <  i;e(5, £i),<,ne(5, £2)  >  and 
e  =  <  £1,  *,£2  >  ^  £'  =  <  •UeC'S'jfii),  *,ne(S',  £2)  >  and 
e  =<£i,<>,£2>=>  ^  =  <  ne(5,  £1),  <>,t)e(5,  £2)  >  and 
e  =  <  £1,  or,£2  >  =>  e'  =  <  Ve(S,ei),  oT,Vg(S,e2)  >  and 
e  =<£i,-,£2>=>  e'  =  <  ne(S',£i), -,ne(S,  £2)  >  and 
£  =  <  — ,ei  >  ^  =  <  — ,'Ue(<S', fii)  >  and 

£  =  <  not,£i  >  ^  =  <  not,ne(5,  £1)  > 

Figure  165  The  Vg  transformation 
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v{S,  where 

\/  s 

S  —  ids^,Pact  > 

s'  =  Vm{S,  s)  and 
s  =  <  X,  :=,  e  > 

s'  =  <  X,  :=,Ve{S,e)  >  and 
s  =  <  if,  e,  then,  5i,  else,  52  >  =>■ 

s'  =  <  if,Ve(S,e),  then,n(5, 5i),  else, n(5, 52)  >  and 
s  =  <  while,  e,  53  > 

s'  =<  while,  Ve(S,  e),v(S,  S3)  >  and 
s  =  <  output,  oport,  E  > 

s'  =  <  output,  oport,  >  and 
E'  =  [ue(5,  e)  \  e  E  E]  and 
s'  E  and 
pos(s,  =  pos{s',^') 

Figure  166  The  v  transformation 
RHO  (  C-7,  RHOSTD) 

using  the  Tj’  transformation.  The  RHOSTD  actual  parameter  is  passed  as  a  parameter  of 
the  message,  the  XLAMDA  actual  parameter  has  become  the  LAMBDA  attribute  of  CLASS-3, 
and  the  actual  parameter  ANGFAC  has  also  become  an  attribute  of  CLASS-3. 

When  duplicate  classes  are  eliminated  from  the  object-oriented  design  using  the 
PBOI  methodology,  the  signature  of  methods  in  the  resulting  class  may  be  changed.  The 
signatures  of  any  messages  that  call  these  methods  must  be  updated  to  match.  Let  the 


class  CLASS-3  attributes  LAMBDA,  ANGFAC 
method  RHO  (  C-3,  RHOSTD  ):  real 
begin 

RHO  :=  RHOSTD 
end 

superclass  USER-OBJECT 


Figure  167  Class  CLASS-3  with  Method  RHO 
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T^{OOD,C)  =  OOD' where 

C  =  <  idc,^c,^C,^o  >  where 
^d,s^,T,Qoi,j,Qf 

ormi  Qreti  Qloct  >}  and 

VCi  G  OOD 

Cl  =  <  idcij^Cii^Cij^o  >  and 

fici  =  ido,T,Qof)jj^,Qf  ormiiQretijQloci:^oi  and 

For  each  m  €  Cgubo 
m  =  <  ids„,Qact  > 

'asi.QactiQform)  and 

m'  =  <  ids^,Qact  >  and  m'  G  C'„j,^  and 
m  #  <  ids^,Qact  >  ^ 

m'  —  m  and  m'  G  C'^ubo 

'Fqj  =  with  m  G  Csubo  replaced  by  m'  e  ci^b.  and 
^Ci  ~  {"^ '^do,T,Qof,j^,Qf  ormi  5  QretitQlocii^oi  and 

C[  =  <  idci,^Ci,^Ct^^o  >  and 
Cl  ^  OOD'  and  C(  G  OOD' 

Figure  168  The  T"  transformation 

Tg  transformation  represent  this  updating  of  message  signatures  as  defined  below.  Let 
OOD  represent  an  object-oriented  design,  let  Cjnsgo  represent  the  collection  of  messages 
in  a  method.  Let  'Us(Qact!  Qform)  represent  whether  or  not  the  number,  order,  and  type  of 
the  actual  parameters  in  Q'act  match  the  number,  order,  and  type  of  the  formal  parameters 
in  Qform-  The  Tg  transformation  is  shown  in  Figure  168.  This  transformation  checks  each 
method  in  each  class  in  OOD  for  messages  being  sent  to  the  method  in  C.  If  the  call 
identifier  of  the  message  m  matches  the  name  of  the  method  in  C,  then  the  Vg  condition 
is  used  to  ensure  the  signature  of  m  matches  the  formals  in  Qform-  The  updated  message, 
m',  replaces  m  in  Cj  and  this  updated  class  replaces  Ci  in  OOD.  If  the  call  identifier  of  m 
is  not  referring  to  the  method  in  C,  then  no  update  is  required  and  the  original  message, 
m,  is  stored  in  Cj. 
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6.10  Category  3  Subprogram  Transformation  (a^) 

This  section  defines  the  formal  transformation  used  to  convert  Category  3  subpro¬ 
grams  to  the  object  paradigm.  As  discussed  in  Section  5.3,  the  transformation  of  Category 
3  subprograms  to  the  object  paradigm  uses  the  PBOI  method  to  update  the  object  design 
developed  so  far. 

At  this  point  of  the  transformation,  there  may  be  several  classes  in  the  design  that 
have  been  built  for  the  same  subprogram.  This  is  because  a  subprogram  may  be  called 
multiple  times  and  a  new  class  is  built  for  the  subprogram  for  each  of  the  calls.  These 
classes  built  for  the  same  subprogram  are  termed  duplicate  classes  because  they  have  the 
same  name.  Duplicate  classes  are  eliminated  from  the  design  by  merging  any  duplicate 
classes  into  a  new  class  that  replaces  the  duplicates  throughout  the  entire  design.  The  set 
of  attributes  for  the  new  class  is  the  intersection  of  the  sets  of  attributes  from  the  duplicate 
classes.  The  set  of  operations  for  the  new  class  is  the  union  of  the  sets  of  operations  from 
the  duplicate  classes.  The  formal  transformation  that  defines  the  removal  of  duplicate 
classes  is  defined  below. 

Let  represent  the  formal  transformation  that  removes  duplicate  classes  from 

the  object-oriented  design.  Let  OOD  represent  an  object-oriented  design.  The 
transformation  is  defined  as  shown  in  Figure  169. 

This  transformation  examines  all  pairs  of  claisses  in  OOD.  Duplicate  classes  are 
identified  by  comparing  the  name  of  the  class.  This  implies  the  generated  name  of  a  class 
must  be  the  same  each  time  a  class  is  built  for  a  subprogram.  If  the  names  of  two  classes 
Cl  and  C'2  are  the  same,  then  a  new  class  C3  is  built  to  represent  the  intersection  of  these 
two  classes.  The  attributes  of  C3  are  built  by  initially  unioning  $^1  and  $^2  and  then 
using  the  transformation  to  remove  those  attributes  not  in  the  intersection  of 
and  #^2  •  The  operations  of  C3  are  built  by  unioning  flc’j  and  Dcj  •  The  union  is  based  on 
the  fact  that  two  operations  are  equal  if  they  have  the  same  name.  The  C3  class  replaces 
the  two  duplicate  classes  in  OOD'.  The  final  step  of  the  transformation  is  to  ensure  any 
calls  to  the  updated  method  in  Cs  match  the  signature  of  the  method. 
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T^Z.iOOD)  =  OOD"  where 
VCi  and  C2  G  OOD 
Cl  ^  C2  and 
Cl  =  <  idc,^Ci,^Ci,^o  > 

C2  =  <  idc,^C2^^C2i^o  >  => 

C3  =  <  idc,^C3,^Cs,^o  >  ci'^d 
^Ca  =  ^Ci  U  ^C2  0,'nd 
VlCi  —  U  ^Ca  o,nd 

^  =  (^Ci  U  ^Ca)  “  (^Ci  n  ^Ca)  o,f^d 
C’3  =  Ti~\00D,Cs,A)  and 
Cl  ^  COD'  and  C2  ^  OOD'  and 
C'^  G  OOD'  and 
OOD"  =  T^{OOD',C'^) 

Figure  169  The  transformation 

Now  that  the  transformation  for  eliminating  duplicate  classes  has  been  defined,  the 
transformation  of  Category  3  subprograms  is  defined  as  follows.  Let  OOD  represent  an 
object-oriented  design,  let  S  represent  the  Category  3  subprogram  to  be  transformed.  Let 
OOD'  represent  the  updated  object-oriented  design  that  results  from  converting  S  to  the 
object  paradigm.  Let  Pform  b®  the  sequence  of  formal  parameters  from  the  subprogram  S. 
Let  Cgubs  the  set  of  imperative  subprogram  calls  in  S.  The  formal  transformation  for 
Category  3  subprograms  is  defined  as  shown  in  Figure  170.  This  transformation  converts 
each  of  the  subprograms  called  by  S  and  unions  all  the  designs  that  are  returned.  This  is 
done  by  applying  the  cr  transformation  to  each  of  the  subprograms  in  C*^j^^.  Initially,  a 
class  is  built  to  represent  the  Category  3  subprogram  by  building  all  the  formal  parameters 
of  the  subprogram  as  attributes  of  the  class.  The  subprogram  5  is  initially  transformed  into 
a  method  included  in  Qc  Each  statement  in  the  subprogram  is  transformed  into  an  object- 
oriented  statement  by  9  and  accesses  to  parameters  of  the  subprogram  are  transformed  by 
6  into  attribute  accesses  of  the  instance  object  r.  This  initial  class  is  added  to  the  design 
built  so  far,  viz.  OOD',  and  the  resulting  design  is  passed  to  the  PBOI  transformation 
along  with  S.  Since  the  PBOI  transformation  has  the  potential  to  change  the  class  C, 
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as{OOD,S)  =  where 

Pin^  Pouti  Prety  ^loc^^S  ^  dTid 
P form  ~  Pin  ®  Pmit  dTld 

V  /  G  Csubs 

I  —  <C  >  PcLCtn  ^  (ITld 
Sn  € 

n 

OOZ)'  =  U(a(OOZ),5i))  where  5i  G  and 

i=l 

C  =  <  idc,  fio,  Aq  >  and 
=  'range{9y{Pform))  o-nd 
T  is  an  instance  of  C  and 
=  8{9{'£,s),t,^c)  o,nd 
Qret  ~  ^v(^Pret}  and 
Qloc  ~  ^v{,Pioc}  and 

Qc  =  {<  ids, Qret,  Qloc,  ^  >}  and 

OOD"  =  Tpi,oi{T+{OOD\C),S)  and 
C'  —  updated  C  G  OOD"  and 
OOD'"  =  T^{OOD",S,C')  and 
OOD«)  =  T^’JOOD'") 

Figure  170  The  <73  transformation 
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procedure  RELAY-EFFNCY 

(  BETA,  XLAMDA,  DIAM,  UPLFAC,  SIGJ,  ZENITH,  MIRRORS,  GEOM, 
AXMAJ,  AXMIN,  SIGJR,  EFFNCY  ) 
begin 

if  MIRRORS  >  0 

then  RNGFAC  :=  0.0; 

K  :=  1; 

while  K  <=  MIRRORS  do  begin 
ANGFAC  :=  GEOM  (  1,  K) ; 

RNGFAC  :=  RNGFAC  +  GEOM  (  2,  K) ; 

TRANS  :=  TRANS 

*  BOUNCE  (  ANGFAC,  RNGFAC,  PROJRA,  SIGB, 

RANGE,  AXMAJ,  AXMIN,  XLAMDA); 

K  :=  K  +  1 
end 

else  endif ; 

ANGFAC  :=  GEOM  (  1,  MIRRORS  +1); 

EFFNCY  :=  TRANS 
end 


Figure  171  Partial  declaration  of  RELAY-EFFNCY 

the  class  C  represents  this  updated  class  after  the  PBOI  transformation.  This  updated 
class  C  is  passed  to  the  transformation  in  order  to  transform  the  subprogram  calls  in 
C  to  messages.  The  class  returned  from  the  Tj"  transformation  replaces  C  in  the  design. 
The  transformation  is  used  to  remove  duplicate  classes  and  the  resulting  design  is 

returned  as  the  result  of  the  transformation. 

For  example,  Figure  171  shows  the  partial  declaration  of  the  imperative  subprogram 
RELAY-EFFNCY  (using  GIL  syntax).  This  subprogram  is  a  Category  3  subprogram  that 
calls  the  BOUNCE  subprogram.  The  first  step  in  converting  RELAY-EFFNCY  to  the  object 
paradigm  is  to  transform  the  BOUNCE  subprogram  and  store  the  resulting  design  in  OOD' . 
Next,  an  initial  class  C  is  built  for  the  RELAY-EFFNCY  subprogram  and  added  to  this 
design.  The  partial  declaration  of  this  class  is  shown  in  Figure  172.  This  class  has  an 
attribute  built  from  each  of  the  formal  parameters  of  the  RELAY-EFFNCY  subprogram.  The 
operations  for  this  class  include  one  method  built  to  implement  RELAY-EFFNCY.  For  brevity. 
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class  CLASS-9  attributes  BETA,  XLAMDA,  DIAM,  UPLFAC, 

SIGJ,  ZENITH,  MIRRORS,  GEOM,  AXMAJ,  AXMIN,  SIGJR,  EFFNCY 
method  RELAY-EFFNCY  (  C-39) 
begin 

end 

superclass  USER-OBJECT 

Figure  172  Classes  after  PBOI  Transformation 

the  statements  of  this  method  are  not  shown.  The  class  CLASS-9  is  added  to  the  design 
OOD'  and  the  resulting  design  is  passed  to  the  Tpioi  transformation. 

6.11  Transforming  Category  1  Subprograms  (g\) 

This  section  defines  the  formal  transformation  for  converting  Category  1  subprograms 
to  the  object-oriented  paradigm.  As  explained  in  Section  5.8,  the  main  program  is  typically 
classified  as  a  Category  1  subprogram.  Category  1  subprograms  other  than  the  main 
program  are  transformed  to  the  object  paradigm  using  the  Category  3  transformation,  (J3. 

More  formally,  let  OOD  represent  an  object-oriented  design,  let  S  be  an  imperative 
subprogram,  and  let  M  be  the  main  program.  Recall  from  Section  5.8  that  the  main  pro¬ 
gram  for  a  system  of  imperative  subprograms  is  identified  by  the  user.  The  transformation 
of  any  Category  1  subprogram  is  defined  as  follows. 

ai{OOD,S)  =  OOD' where 

S  ^  M  OOD'  =  <73(007?,  S)  and 
S  =  M  =^OOD'  =  aM{OOD,S) 

This  transformation  determines  whether  the  input  subprogram  is  the  main  program 
or  not.  If  it  is  not  the  main  program,  then  the  <73  transformation  is  used.  If  it  is  the  main 
program,  then  the  transformation  specifically  defined  for  the  main  program  is  used. 

The  rationale  for  the  transformation  of  the  main  program  is  given  in  Section  5.8. 
Specifically,  there  are  three  updates  done  on  the  design  while  transforming  the  main  pro¬ 
gram.  First,  duplicate  object  instances  are  replaced  in  the  main  program  with  a  single 
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object  instance.  Second,  the  “GET-”,  “SET-”,  and  “CREATE-”  methods  are  added  to 
each  class  in  the  design.  Finally,  overlapping  classes  in  the  design  are  merged  into  a  new 
class  and  instances  of  the  overlapping  classes  are  replaced  with  a  single  instance  of  the  new 
class.  The  transformations  that  formalize  these  updates  are  defined  below  and  an  example 
of  each  transformation  is  provided. 

6.11.1  Removing  duplicate  objects.  This  section  defines  the  transformations 
needed  to  remove  duplicate  objects  from  the  main  program.  Two  duplicate  objects  are 
instances  of  the  same  class  that  are  built  using  the  same  data  items.  Duplicate  objects  are 
eliminated  by  replacing  the  two  assignment  statements  that  are  used  to  build  the  instances 
with  a  new  assignment  statement  that  builds  just  one  instance.  In  order  to  replace  the  two 
variables  that  hold  the  duplicate  objects,  the  and  transformations  are  defined  in 
this  section. 

The  transformation  replaces  any  occurrences  of  the  vi  variable  in  an  expression 
e  with  the  V2  variable,  which  results  in  a  new  expression  e.  Let  the  pos{v,P)  predicate 
indicate  the  ordinal  position  of  a  variable,  v,  in  the  sequence,  P.  The  transformation 
is  defined  as  shown  in  Figure  173. 

The  transformation  has  been  defined  as  shown  in  Figure  174.  This  transforma¬ 
tion  uses  the  formal  definitions  of  imperative  statements  in  its  definition. 

Let  represent  the  transformation  that  removes  duplicate  object  instances  from 
the  object-oriented  design.  Let  OOD  represent  the  object-oriented  design,  let  C  represent 
the  overall  system  class  built  for  the  main  program,  and  let  idmain  be  the  name  of  the  main 
program.  The  transformation  is  defined  as  shown  in  Figure  175.  This  transformation 
compares  the  assignment  statements  in  the  method  built  for  the  main  program  in  order  to 
find  “CREATE-”  messages  that  are  instantiating  duplicate  objects.  The  transformation 
replaces  the  ii  and  i2  assignment  statements  with  the  i^  assignment  statement  and  the 
variables  vi  and  V2  with  the  variable  v^. 

For  example.  Figure  176  shows  the  overall  system  class  CLASS-SYSTEM.  The  variables 
C-5  and  C-6  hold  object  instances  that  are  passed  to  the  BOUNCE  method.  Both  object 
instances  are  built  from  CLASS-2  using  the  data  items  ANGFAC  and  BEAMRA  and  are  duplicate 
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vi,i)2)  =  e' where 
e  =  <  idg^ ,  Pact  ^  dTld  Vi  G  Pact 
e'  =  <  ids^.P'act  >  and 
^  PLct  o-nd  V2  e  Pact  and 
pos{vi,  Pl^ct)  =  pos{v2,  Pact)  and 
gom-variable(e)  ande  =■  vi 
e'  =  i;2  and 

gom-literal-boolean(e)  e'  =  e  and 
gom-literal-integer(e)  =>  e'  =  e  and 

gom-literal-real(e)  e'  =  e  and 

gom-literal-string(e)  e'  —  e  and 

e  =  <  ei,  +,62  >  ^  e'  =  <  vf"^{ei,vi,V2),  +,vf^^(e2,vi,V2)  >  and 
6  —  <  61,  and,  62  >  =>  e'  =  <  vf^'’^{6i,V\,V2),  &ndi,vf^^{e2,vi,V2)  >  and 
6  =  <  6i,  Sz,62  >  =+  e'  =  <  vf^P{6i,vi,V2),  nf“^(e2, t>2)  >  and 

6  =  <  ei,  /,62  >  =+  e'  =  <  ■uf“P(ei,ui,V2).  /,nf“P(e2,  vi,  V2)  >  and 
6  =  <  ei,  =,62  >  =+  e'  =  <  vf^^{6i,vi,V2),  =,vf^^{62,vi,V2)  >  and 

6  =  <  61,  **,e2>=^  e'  =  <  ne“*’(6i,vi,t;2),  **,vf'^^{62,vi,V2)  >  and 

6  =  <  ei,>-,62  >  =>  6'  =  <vf^‘‘‘{6i,Vi,V2),>=^,vf^'P{e2,vi,V2)  >  and 

6  =  <  61,  >,  62  >  6'  =  <  nf“^(ei,vi,V2),  >,nf“^(e2,'yi,'y2)  >  and 

6  =  <  61,  <=,62  >  6'  =  <  vf^^{6i,Vi,V2),  <=,vf^P{e2,vi,V2)  >  and 

6  =  <  61,  <,62  >  =^>  6'  =  <  ne“^(ei,ni,i;2),  <,nf“^(62,'i;i,'i;2)  >  and 

e  =  <  ei,  *,62  >  =»  6'  =  <  vf^^{ei,vi,V2),  *,vf^^{62,vi,V2)  >  and 

a  =<  61,0,62  >=^  e'  =  <  nf“^(6i,vi,'y2))  <>)nf“^(e2,ni,i;2)  >  and 
6  =  <  61,  or,  62  >  =>  6'  =  <  vf^P{6i,vi,V2),  OT,vf^^{62,vi,V2)  >  and 
a  =<6i,-,e2>=^  e'  =  <  nf“*’(6i,ni,'y2), -,ng“^(62,T;i,?;2)  >  and 
e  =  <  — ,61  >  ^  =  <  —,v'^^{ei,vi,V2)  >  and 

6  =  <  not,  61  >  =»  6^  =  <  not,t;g“^(6i,vi,t;2)  > 

Figure  173  The  transformation 
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v^'^^{'^,vi,V2)  —  where 
V  s  €  "S' 

5  —  <C  Pact  ^  QjTld  'Uj  G  Pact 

s  =  <  5  Pact  ^  dnd 

^  Pact  o^nd  V2  G  Pact  and 
pos{vi,  P'act)  =  pos(t;2,  Pact)  and 
s  =  <  X,  :=,  e  >  =4> 

s'  =  <  X,  :=,vf^^{e,vi,V2)  >  and 
s  =  <  if,  e,  then,  5i,  else,  52  > 

s'  —  <  if,vf'^(e,vi,V2),  then,n'*“^(5i,t;i,?;2),  else, n'^“P(52,'yi,'i;2)  >  and 
s  =  <  while,  e,  53  > 

s'  =  <  while,  vf'^(e,vi,V2),v^^^ {S3,  vi,V2)  >  and 
s  =  <  output,  oport,  E  > 

s'  =  <  output,  oport,  E'  >  and 
E'  =  [uf“^(e,r;i,U2)  j  e  G  iS]  and 
s'  G  'if'  and 
pos{s,'9)  =  pos{s',if') 

Figure  174  The  transformation 

PobfiOOD,  C)  =  OOD'  where 

C  =  <  CLASS-SYSTEM,  $c,fic,Ao  >  and 

He  —  {■^  idiaaini'^^^t^-iQret^Qloctif  and 
V  ii  and  i2  &  if  and 

[zi  =  <  x)i,  ;=,  <  CREATE  —  C\,  [di,  ^2,  •  •  •  ,  dn]  >  >  and 
Z2  =  <  V2,  :=,  <  CREATE  —  Ci,  [di,  d2,. . .  ,dn]  >  >  ]  ^ 
iz  =  <  V3,  :=,  <  CREATE  —  Ci,  [di, d2, . . .  ,dn]  >  >  and 
il  0  'if'  and  «2  ^  and  13  6  ’S'  and 
pos{ii,'^)  =  pos{i3,'if')  and 
if"  =  and 

if'"  =  v^"'^{^,V2,V3)  and 
He  =  {■<  0)  Qret>  Q/oc) and 

C  =<  CLASS-SYSTEM,  $c,nc>^0  >  and 
COD'  =  T+{T-{OOD,C),C') 

Figure  175  The  Tg^J'  transformation 
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class  CLASS-2  attributes  ANGFAC,  BEAMRA 
method  CREATE-CLASS-2 

(  A-ANGFAC,  A-BEAMRA  ):  a  CLASS-2 
begin 

end 

class  CLASS-SYSTEM  attributes 
method  BMDSIMl  (  C-9  ) 
begin 

C-5  :=  CREATE-CLASS-2  (  ANGFAC,  BEAMRA  ); 

C-6  :=  CREATE-CLASS-2  (  ANGFAC,  BEAMRA  ); 

BOUNCE  (  C-4,  C-5,  C-6  ); 

end 

Figure  176  Duplicate  object  instances 

object  instances.  Figure  177  shows  that  the  method  BMDSIMl  has  been  updated  by  replacing 

class  CLASS-SYSTEM  attributes 
method  BMDSIMl  (  C-9  ) 
begin 

C-7  :=  CREATE-CLASS-2  (  ANGFAC,  BEAMRA  ); 

BOUNCE  (  C-4,  C-7,  C-7  ); 

end 

Figure  177  Duplicates  removed 

the  duplicate  object  instances.  The  variables  C-5  and  C-6  have  been  replaced  with  the 
variable  C-7.  The  new  instance  is  instantiated  using  the  CREATE-CLASS-2  method,  stored 
in  C-7,  and  passed  to  the  BOUNCE  method  in  place  of  C-5  and  C-6. 

6.11.2  Generating  Methods  (kJ.  As  part  of  the  transformation  to  merge  over¬ 
lapping  classes,  the  “SET-”,  “GET-”,  and  “CREATE-”  methods  are  added  to  each  class 
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class  CLASS-17  attributes  DWELLT 
method  CREATE-CLASS-17  (  A-DWELLT  ) :  a  CLASS-17 
begin 

INST-CLASS-17  :=  new  (  CLASS-17  ); 

SET-DWELLT  (  INST-CLASS-17,  A-DWELLT  ); 
CREATE-CLASS-17  :=  INST-CLASS-17 
end 

method  GET-DWELLT  (  C-10  ) :  real 
begin 

GET-DWELLT  :=  C-10. DWELLT 
end 

method  SET-DWELLT  (  C-11,  VAL-10  ) 
begin 

C-11. DWELLT  :=  VAL-10 
end 


Figure  178  Instantiation  Method  for  CLASS-17 

in  the  object-oriented  design.  This  section  defines  a  formal  transformation  that  generates 
these  methods. 

Figure  178  shows  the  “SET-”,  “GET-”,  and  “CREATE-”  methods  for  the  class 
CLASS- 17.  The  mechanics  of  “SET-”  and  “GET-”  methods  were  covered  in  Section  6.3, 
so  they  won’t  be  covered  further  here.  The  “CREATE-”  method  for  this  class  is  explained 
in  detail. 

The  CLASS- 17  class  has  only  one  attribute  DWELLT,  so  the  “CREATE-”  method  for 
this  class  expects  one  parameter  that  is  used  to  initialize  the  attribute.  The  “CREATE-” 
method  includes  a  call  to  the  intrinsic  functional  method  named  new,  which  returns  a 
new  instance  of  the  class.  The  INST-CLASS-17  local  variable  holds  the  newly  instantiated 
object  and  is  sent  the  “SET-”  method  to  assign  the  input  value  of  the  DWELLT  attribute. 
Finally,  the  new  initialized  instance  is  returned  as  the  result  of  this  method  call. 

Let  K  be  a  transformation  that  adds  the  “SET-” ,  “GET-” ,  and  “CREATE-”  methods 
to  a  class.  Let  C  be  a  class,  and  let  r  be  the  target  object,  which  is  an  instance  of  C.  Let 
/?  be  an  expression  that  will  be  passed  as  the  new  value  in  “SET-”  methods.  Let  SET-a 
represent  a  symbol  that  results  from  prepending  “SET-”  to  the  name  of  the  attribute 
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k{C)  =  C  where 

C  =  <  idc,  fie,  A  >  and 
For  each  a  € 

s  =<  SET-a,T,  [],[/?],[],[],[  ],n  >  and 
n  =  [<  T.a,  :=,  /3  >]  and 
g  =<  GET-a,r,  [],[],[  ],[o],[  ],^’ >  and 
'F  =  [<  GET-a,  :=,  T.a  >]  and 
s  G  and  g  G  ^(7 
For  each  a  G 
A-a  G  X 

<  SET-a,  [  INST-ific,  A-a  ]  >  G  1/’ 

H  =  [<  INST-zdc)  new(idc)  >, 

<  CREATE-it^C)  •— )  INST-zdc  >]  and 
r  =  <  CREATE-idc,  r,  [  ], x,  [INST-idc],  [INST-idc],  S  >  and 
r  G  il'c  and 

C'  =  <  idc,  $C)  ^  > 

Figure  179  The  k  transformation 

a  G  ^C‘  Similarly,  let  GET-a  represent  the  symbol  resulting  from  the  prepending  of  “GET- 
”  to  the  name  of  a.  Let  CREATE-zdc  represent  the  symbol  that  results  from  prepending 
“CREATE-”  to  the  name  of  the  class  C.  Let  A-a  represent  the  symbol  resulting  from 
prepending  “A-”  to  the  name  of  a.  This  symbol  is  used  for  formal  parameters  in  the 
“CREATE-”  method.  Let  x  represent  the  sequence  of  these  formal  parameters.  Let 
INST-$id_{C}$  represent  the  symbol  resulting  from  prepending  “INST-”  to  the  name  of 
the  class  C.  Let  •0  represent  the  sequence  of  “SET-”  messages  used  to  assign  the  input 
values  to  the  object  attributes.  The  k  transformation  is  defined  as  shown  in  Figure  179. 

All  the  methods  shown  in  Figure  178  are  generated  by  the  transformation 

k(CLASS-17  ) 
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K-I(C)  =  C' where 

C  =  <  idc,^Ct^Ci  ^ 

For  each  a  €  $c 

s  =<  SET-a,r,  [],[/?],[  ],[],[  ],n  >  and 
g  =<  GET-a,T,  [],[],[],  [a],  [],«' >  and 
s  ^  Vl'q  and  g  ^  Q'q  and 

r  =  <  CREATE-idc,T,  [  ],x,  [INST-idc],  [INST-idc],  S  >  and 
r  ^  ^l'(j  and 

C'  =  <idci^Ci^'ci^> 

Figure  180  The  /c“^  transformation 

The  K  transformation  returns  a  new  class  C'  that  must  replace  the  old  class  C  in  the  object 
design.  This  updating  of  the  object  design  is  not  shown  here. 

As  part  of  the  PBOI  method,  it  is  in  some  cases  required  to  remove  the  “SET-”, 
“GET-”,  and  “CREATE-”  methods  from  a  class.  For  example,  when  merging  two  classes. 
For  this  reason,  the  k  transformation  is  reversible.  The  “inverse”  transformation  for  k  is 
defined  below. 

Let  be  the  inverse  of  k.  The  k  transformation  is  defined  as  shown  in  Figure  180. 
All  the  methods  shown  in  Figure  178  are  removed  by  the  transformation 

K-nCLASS-17  ) 

As  with  K,  the  transformation  returns  a  new  class  C  that  must  replace  the  old  class 
C  in  the  object  design.  This  updating  of  the  object  design  is  not  shown. 

6.11.S  Merging  overlapping  classes.  The  transformation  is  used  in  the 

main  program  to  merge  overlapping  classes.  Let  OOD  represent  the  design  built  so  far  and 
let  C  represent  the  class  built  for  the  main  program.  Let  set{Q)  represent  the  conversion 
of  the  sequence  Q  to  a  set.  Let  Qact  represent  a  sequence  of  actual  parameters  and 
let  Qform  represent  a  sequence  of  formal  parameters.  Let  v s{Q act-,  Q form)  indicate  the 
number,  order,  and  type  of  the  parameters  in  Qact  matches  the  number,  order,  and  type 
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of  the  parameters  in  Qform-  The  transformation  is  defined  as  shown  in  Figure  181. 

This  transformation  examines  each  assignment  statement  in  the  method  built  for  the  main 
program  in  order  to  find  “CREATE-”  messages  that  are  building  instances  of  overlapping 
classes.  The  classes  from  the  “CREATE-”  messages  in  the  ii  and  12  assignment  statements 
are  merged  to  form  the  new  class  C3.  The  overlapping  classes  Ci  and  C2  do  not  appear 
in  the  updated  design,  but  the  new  class  does.  The  actual  parameters  for  the  “CREATE- 
”  message  in  the  new  assignment  statement  13  are  built  from  the  actual  parameters  in 
the  “CREATE-”  messages  in  ii  and  12.  The  v  predicate  ensures  that  this  new  sequence 
of  actual  parameters  matches  the  number,  order,  and  type  of  the  formal  parameters  in 
the  “CREATE-”  method  of  the  new  class  Ca.  The  i\  and  i2  assignment  statements  are 
replaced  by  the  new  assignment  statement  ^3  and  the  variables  i;i  and  V2  are  replaced  by 
the  variable  v^.  The  updated  system  class  replaces  the  original  system  class  in  the  00 D' 
design  and  the  resulting  design  is  returned  as  the  result  of  the  transformation. 

For  example.  Figure  182  shows  the  classes  CLASS-2,  CLASS-3,  and  CLASS-SYSTEM. 
In  the  BMDSIMl  method,  the  variable  C-5  holds  an  instance  of  CLASS-2  that  is  built  using 
the  data  items  ANGFAC  and  BEAMRA.  The  variable  C-8  holds  an  instance  of  CLASS-3  that 
is  built  using  the  data  items  ANGFAC  and  RHOSTD.  Since  the  sequence  of  actuals  have  the 
ANGFAC  data  item  in  common,  the  classes  CLASS-2  and  CLASS-3  overlap  and  are  merged 
into  one  new  class. 

Figure  183  shows  the  result  of  merging  CLASS-2  and  CLASS-3  into  the  new  class 
CLASS-10.  In  the  BMDSIMl  method,  the  variable  C-11  holds  the  new  instance  instantiated 
from  CLASS-10.  The  C-11  variable  is  passed  to  the  BOUNCE  message  in  place  of  the  variables 
C-5  and  C-8.  The  design  is  updated  by  removing  CLASS-2  and  CLASS-3  and  adding 
CLASS-10. 

6.11.4  Converting  the  Main  Program.  This  section  defines  the  formal  transfor¬ 
mation  required  to  convert  the  main  program.  In  the  main  program,  as  the  calls  to  other 
subprograms  are  transformed  into  messages,  the  object  instances  required  by  the  signature 
of  the  method  being  invoked  must  be  built.  For  each  message  being  built,  it  is  assumed 
that  the  corresponding  method  exists  in  some  class  in  the  design. 
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TdaTiOOD,C)  =  OOD"  where 

C  =<  CLASS-SYSTEM,  0,fic,Ao  >  and 

Clc  —  {<  *^mam5 "r)  05  0) 0j  Qioc) and 
ii  and  i<i,  and 
pos(ii,'®f)  <  pos(i2,'^)  and 

ii  =  < 'Ui,  :=,  <  CREATE  —  Ci,Qacti  ^  ^ 

^2  =  <  ■*^2)  :=)  <  CREATE  —  C2,Qact2  >  > 

sci(Qacti)  C  set(Qoct2)  7^  0 

Cl  G  OOD  and  C[  —  k;“^(Ci)  and 
C2  €  OOD  and  C2  =  k~^{C2)  and 
Cj  =  <  )  ^Cj  5  )  Aq  ^  and 

C2  =  <  idc'^j^C^jOc'/, Ao  >  and 
C3  =  <  idc3,$C3)f^C3  5Ao  >  and 

$C3  = 

S^^3  “*  LJ  and 

Cl  ^  COD'  and  C2  0  COD'  and  «(C3)  G  COD'  and 
iz  —  <  '^3,  '=,  <  CREATE  —  C3,  Qocta  >  >  where 

Qactz  ~  Qacti  ©  Qact2  and 
'asiQactsiQ formcREATE-C^) 

ii  ^  and  ^2  ^  'S''  and  iz  E  ^  and 
pos{ii,^)  =  pos{izi^')  and 
V'  =  n‘^“P(^,t;i,'i;3)  and 
=  i;‘*“P(’i^,i;2,'i;3)  and 
~  ^^maini'^t^t^iQretiQloo^  and 

C'  =  <  CLASS-SYSTEM,  #c,J^c,Ao  >  and 
OOD"  =  r+(T-(OOD',C),C') 

Figure  181  The  transformation 
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class  CLASS-2  attributes  ANGFAC,  BEAMRA 
method  CREATE-CLASS-2 

(  A-ANGFAC,  A-BEAMRA  ):  a  CLASS-2 
begin 

end 

method  CAPTURE  (  C-2  )  :  real 
begin 

end 

class  CLASS-3  attributes  ANGFAC,  RHOSTD 
method  CREATE-CLASS-3 

(  A-ANGFAC,  A-RHOSTD  ):  a  CLASS-3 
begin 

end 

method  RHO  (  C-3  )  :  real 
begin 

end 


class  CLASS-SYSTEM  attributes 
method  BMDSIMl  (  C-9  ) 
begin 

C-5  :=  CREATE-CLASS-2  (  ANGFAC,  BEAMRA  ); 
C-8  :=  CREATE-CLASS-3  (  ANGFAC,  RHOSTD  ); 
BOUNCE  (  C-4,  C-5,  C-8  ); 

end 


Figure  182  Overlapping  object  classes 
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class  CLASS-10  attributes  ANGFAC,  BEAMRA,  RHOSTD 
method  CREATE-CLASS-10 

(  A-ANGFAC,  A-BEAMRA,  A-RHOSTD  ):  a  CLASS-10 
begin 

end 

method  CAPTURE  (  C-10  )  :  real 
begin 

end 

method  RHQ  (  C-10  )  :  real 
begin 

end 

class  CLASS-SYSTEM  attributes 
method  BMDSIMl  (  C-9  ) 
begin 

C-11  :  = 

CREATE-CLASS-10  (  ANGFAC,  BEAMRA,  RHOSTD  ); 
BOUNCE  (  C-4,  C-11,  C-11  ); 

end 


Figure  183  Overlapping  classes  merged 


223 


The  transformation  generates  a  sequence  of  assignment  statements  that  instan¬ 
tiate  the  object  instances  required  and  stores  them  in  variables  used  as  actual  parameters 
in  the  message.  Let  Vc  represent  a  GOM  variable  generated  to  hold  the  target  object  in¬ 
stance.  Let  Vi  represent  one  of  the  variables  generated  to  hold  the  other  object  instances 
required  for  a  specific  message,  m.  Let  the  Va{Qacti^Qformo)  predicate  indicate  whether 
or  not  the  number,  order,  and  type  of  the  actual  parameters  in  Qacti  match  the  number, 
order,  and  type  of  the  parameters  in  Qformo-  The  transformation  is  shown  in  Fig¬ 
ure  184.  This  transformation  builds  an  assignment  statement,  asi,  that  includes  a  call  to 
the  “CREATE-”  message  from  class  C2  in  order  to  instantiate  the  target  object  c.  The 
actual  parameters  to  be  sent  to  the  “CREATE-”  message  are  determined  by  using  the  //* 
transitive  closure  and  the  actual  parameters  from  the  subprogram  call  1.  The  assignment 
statement  asi  stores  the  instance  into  the  variable  Vc-  For  each  object  instance  q  in  Qobj, 
an  assignment  statement  is  built  that  includes  a  call  to  the  “CREATE-”  message  from  g’s 
class  Q.  The  assignment  statement  stores  the  instance  in  the  variable 

For  example,  consider  the  following  message  from  the  main  program. 

BOUNCE  (  C-4,  C-5,  C-8  ); 

This  message  is  passing  the  C-4,  C-5,  and  C-8  object  instances  to  the  BOUNCE  method.  The 
target  object  of  the  message  is  C-4,  an  instance  of  CLASS-4,  which  includes  the  BOUNCE 
method.  For  this  example,  assume  that  C-5  and  C-8  are  instances  of  CLASS-2  and  CLASS-3, 
respectively.  The  original  call  to  the  subprogram  BOUNCE  is  shown  below. 

BOUNCE  (  XLAMDA,  ANGFAC,  BEAMRA,  RHOSTD  ); 

The  sequence  of  statements  generated  to  build  the  instances  required  for  this  message  are 
shown  below. 

C-4  :=  CREATE-CLASS-4  (  XLAMDA  ); 

C-5  :=  CREATE-CLASS-2  (  ANGFAC,  BEAMRA  ); 

C-8  :=  CREATE-CLASS-3  (  ANGFAC,  RHOSTD  ); 

The  sequence  of  assignment  statements  returned  from  the  transformation  must 
be  spliced  into  the  sequence  of  statements  in  the  main  program  right  before  the  message 
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T^{OOD,l,m)  =  AS  where 
I  =<  ids,  Pact  >  and 
m  =  <  ids,Qact  >  and 
Qact  ~  [c]  ©  Qobj  ©  Qform  and 
instance{c,  C2)  and 
C2  €  OOD  and 

C2  =  <  idc2 ,  ^C2 )  ^Ci  5  -^0  >  and 
o  G  fica  and 

o  =  {<  CREATE-zdcai'^J  ])Q/  ormo>  Qretoi  Qlocoi 
Qacti  ~  [^vi^k)  I  ^  Pact  and 
Sv{fM  (<^fc))  €  Qformo  ]  and 
nsiQacti !  Qformo)  and 

ASi  =  [<  Vc,  :=,<  CREATE-C2,Qocfi  >  >  ] 

V  5  €  Qobj 

instance{q,  Ci)  and 
Ci  E  OOD  and 

Ci  =  <  idci,^Ci,^Ci,^Q  >  and 
Oi  E  flci  and 

Oi  =  {<  CREATE- Cj,  To^,  [],  Qreto^ )  Qioc 

Qacti  ~  {^j  I  i^j)  ^  Qformo^  ]  and 
^siQ acti ,  Q  formoi  ^  O^nd 

asi  =  <  Vi,  :=,<  CREATE-idQ ,  Qoct .  >  >  and 
asi  E  AS2  and 
AS  =  ASi  ©  AS2 

Figure  184  The  transformation 


>}  and 


,.,^0i  >}  and 
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vl\OOD,S,e)  =  A5  where 
e  =  <  ids^,Qact  >=^ 

AS  =  T^(OOD,e,Vm(OOD,S,e))  and 
e  =  <  ei,  +,62  >  AS  =  v^^{OOD,S,ei)  ©  Vg^{OOD,  S,  62)  and 
e  =  <  61,  and,  62  >  =>  AS  =  d“(OOD,  S,  61)  ©  ^“^(OOZ),  S,  62)  and 
6  =  <  61,  &:,  62  >  AS  =  n“(OOjD, S, 61)  ffi  iig*(OC>£>,  S,  62)  and 
6  =  <  61,  /,  62  >  =+  AS  =  Vg‘‘(OOD,S,ei)  ©  v^‘{OOD,S,e2)  and 

6  =  <  61,  =,62  >  AS  =  t;“*(00£),  S,  61)  ©  t;“®(OOZ>,  S,  62)  and 

6  =  <  61,  **,62  >  AS  =  nf  (OOD,S,6i)  ©  t;“*(OOD,S,62)  and 

6  =  <  61,  >=,62  >  =+  AS  =  Vg^{OOD,S,ei)  ©  ^“^(OOZ),  S,  62)  and 

6  =<6i,>,e2>=+  AS  =  Vg^(OOD,S,ei)  ©  Vg^{OOD,S,e2)  and 
6  =  <  61,  <=,  62  >  AS  =  ng®(OOD,S,  ei)  ©  n“®(C)OZ),  S,  62)  and 
6  =  <  6i,<,62  >  =+  AS  =  Vg^{OOD,S,ei)  ©  n“®(OOZ>,  S,  62)  and 

6  =  <  61,  *,  62  >  =+  AS  =  n“*(OOjD,  S,  61)  ©  ng*(OOD,  S,  62)  and 

6  =<  61,0,62  >=+  AS  =  Vg^{OOD,S,ei)  ©  Vg^{OOD,S,e2)  and 
6  =  <  61,  or,  62  >  =+  AS  =  Vg^{OOD,S,ei)  ©  Vg^{OOD,S,  62)  and 
6  =  <  61,— ,62  >  =+  AS  =  Vg^(OOD,S,ei)  ©  ^“*(001), S, 62)  and 

6  =  <  — ,61  >  AS  =  ng*(OOD, S, 61)  and 

6  =  <  not,  61  >  =>  AS  =  ng®(00£>,  S,  61) 

Figure  185  The  n®*  transformation 

m.  The  n®*  transformation,  defined  in  Figure  185,  is  used  to  build  the  sequence  of  assign¬ 
ment  statements  for  functional  messages  that  appear  in  expressions.  Let  OOD  represent 
the  object-oriented  design,  and  let  S  represent  the  original  subprogram.  The  vm  trans¬ 
formation  is  defined  to  update  the  statements  fi:om  the  main  program,  ’Jf,  by  replacing 
all  subprogram  calls  with  messages.  For  procedural  messages,  the  sequence  of  assignment 
statements  generated  by  the  transformation  is  spliced  into  before  the  message.  For 
functional  messages,  the  sequence  of  assignment  statements  is  spliced  into  right  before 
the  statement  that  includes  the  message.  The  vm  transformation  is  defined  in  Figure  186. 
This  transformation  uses  the  Vm  and  transformations  to  transform  subprogram  calls 
into  messages.  The  reduce  operation  is  used  for  output  statements  in  order  to  combine 
the  results  of  the  u®*  transformation  of  the  expressions  using  the  ©  operator. 
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vm{S,  'Jf)  =  where 
V  s  G 

'S'  =  '5'l  ©  [s]  ©  '$^2  dnd 
s  =  K  idg^,  Pact  ^  ^ 
s'  =  VmiS,  s)  and 
AS  =  T^{OOD,s,s')  and 
s  =  <  X,  :=,e  >  => 

s'  =  <  X,  :=,Ve(S,e)  >  and 
AS  =  v^^(OOD,S,e)  and 
s  =  <  if,  e,  then,  5i,  else,  ^2  > 

s'  =  <  ii,VeiS,e),  then,t;jv/(5, 5i),  else,  (5, 52)  >  and 
AS  =  v^^{OOD,S,e)  and 
s  =  <  while,  e,  53  >  =» 

s'  =<  while,  De(S,e),i>Af (5,53)  >  and 
AS  =  vf{OOD,S,e)  and 
s  =  <  input,  iport,  E  >  ^ 
s'  =  s  and 

s  —  <  output,  oport,  E  > 

s'  =  <  output,  oport,  >  and 
E'  =  [we(5,  e)  I  e  G  and 
AS  =  redttce(©,  [Ug®(C>0£),5,  e)  |  e  G  £■])  and 
’5^'  =  ©  AS  ©  [s']  ©  ’J'2  and 


Figure  186  The  transformation 


227 


class  CLASS-SYSTEM  attributes 
method  BMDSIMl  (  C-9  ) 
begin 

BOUNCE  (  XLAMDA,  ANGFAC,  BEAMRA,  RHOSTD  ); 
end 


Figure  187  BMDSIMl  before  BOUNCE  converted 

The  formal  transformation  applies  the  vm  transformation  to  the  main  method 
of  the  overall  system  class  and  is  defined  zis  follows.  Let  OOD  represent  an  object-oriented 
design,  let  M  represent  the  main  program  from  the  imperative  system,  let  C  represent  the 
CLASS-SYSTEM  built  for  the  main  program. 

T]^{OOD,M,C)  =  OOD' where 

O  =  <  CLASS-SYSTEM,  0,  fic,  Aq  >  and 
Dc  ~  main  >}  and 

^main  ~  and 

~  and 

C  =<  CLASS-SYSTEM,  0,D;7,Ao  >  and 
OOD'  =  T+iT-{OOD,C),C') 

For  example.  Figure  187  shows  the  CLASS-SYSTEM  main  program  method  BMDSIMl 
before  the  transformation.  The  BOUNCE  subprogram  call  has  not  yet  been  converted 

to  a  message.  Figure  188  shows  the  BMDSIMl  method  after  the  BOUNCE  subprogram  call 
has  been  converted  to  a  message  and  the  object  instances  required  for  the  message  have 
been  inserted. 

In  order  to  convert  the  main  program,  the  (Tm  transformation  is  defined  in  Figure  189. 
Let  OOD  represent  an  object-oriented  design  and  let  M  represent  the  main  program. 
This  transformation  takes  the  main  program,  M,  as  input  and  unions  the  designs  built 
from  applying  a  to  each  of  the  subprograms  called  by  M.  Each  subprogram  called  by 
the  main  program  will  also  apply  a  to  any  subprograms  it  calls.  This  formalizes  the 
depth-first  approach  used  in  the  PBOI  methodology.  The  resulting  designs  are  unioned 
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class  CLASS-SYSTEM  attributes 
method  BMDSIMl  (  C-9  ) 
begin 

C-4  :=  CREATE-CLASS-4  (  XLAMDA  ); 

C-5  :=  CREATE-CLASS-2  (  ANGFAC,  BEAMRA  ); 

C-8  :=  CREATE-CLASS-3  (  ANGFAC,  RHOSTD  ); 

BOUNCE  (  C-4,  C-5,  C-8  ); 

end 

Figure  188  BMDSIMl  after  BOUNCE  converted 

together  to  build  OOD' .  The  CLASS-SYSTEM  class  is  built  with  no  attributes  and  the  main 
program  statements  are  converted  using  the  0  transformation.  There  is  no  need  to  use  the 
8  transformation  because  CLASS-SYSTEM  has  no  attributes.  Each  of  the  subprogram  calls 
is  converted  to  a  message  using  the  transformation.  Duplicate  classes  are  removed  by 
the  transformation,  duplicate  objects  are  removed  by  the  transformation,  and 

overlapping  classes  are  merged  using  the  transformation. 

6.12  Eliminating  Category  4  and  Category  5  Subprograms 

This  section  defines  the  formal  transformations  used  to  convert  Category  4  and  Cate¬ 
gory  5  subprograms  (in  the  GIM)  into  collections  of  Category  2  or  Category  3  subprograms 
(in  the  GIM).  These  transformations  are  built  using  the  formal  definitions  of  a  subprogram 
and  subprogram  call  provided  in  Chapter  III.  Since  only  procedures  are  allowed  to  have 
multiple  outputs,  the  transformations  are  restricted  to  this  form  of  subprogram. 

As  presented  in  Chapter  III,  a  procedure,  S,  is  represented  by  the  following  tuple. 


<  ids  >  Pinj  Pouti  [],Pl  OC)  s  > 


Let  Sj,  represent  the  program  slice  on  the  statements  in  S  required  to  produce  p. 
Weiser  [76]  defines  a  program  slice  as  a  projection  of  the  behavior  of  the  original  procedure. 
Let  TT  represent  a  function  that  indicates  a  sequence  of  statements,  Sp,  projects  the  behavior 
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(TMipOD.M)  =  where 

M  —  <C  Pioct^m  ^  und 

V  /  G  Cgy})j^ 

Z  =  <  ids^ ,  Pactn  ^  and 

Sn  e 

n 

OOZ)'  =  U(  a{OOD,  Si))  where  and 

i=l 

OOD"  =  TiZ,(OOD')  and 

V  Cj  G  OOD" 

K{Ci)  G  OOD'"  and 

C  =  <  CLASS-SYSTEM,  0,f2c,Ao  >  and 

instance{T,  C)  and 
=  6{T,m)  and 
Qloc  ~  ^v(^Ploc)  and 

Dq  —  {<C  ^^matn)  0)  0)  Qioc) and 

OOd(4)  =  T^{OOD'",M,C)  and 
C'  =  updated  C  G  OOD^^^  and 
OOD^^'^  =  T^^f(OOD^'^\c')  and 
C"  =  updated  O'  G  OOD^^^  and 

ooD^^'>  = 

Figure  189  The  ctm  transformation 

of  another  sequence  of  statements,  E,  in  order  to  produce  a  variable  p.  Formally, 

Sp  =  7r(S,p) 

Any  sequence  of  statements  that  meets  the  condition,  tt,  is  a  program  slice  of  the  original 
procedure  and  produces  the  single  data  item  p.  A  new  subprogram  built  from  this  program 
slice  is  represented  as  a  tuple  that  is  defined  as  follows.  Let  idsp  represent  the  name  of 
the  new  subprogram.  Let  Pinp  represent  the  input  parameters  that  are  referenced  in  the 
program  slice,  such  that  Pin^  C  Let  Pjocp  represent  any  local  variables  referenced  in 
the  program  slice,  such  that  Piocp  C  Piocp-  Given  a  data  item,  p  G  Pmit  that  is  produced 
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by  S,  the  program  slice,  Sp,  is  defined  as  shown  below. 


<  idsp  )  Pirip  5  [p].[  ],jP/0Cp,7r(Sp)  > 

As  presented  in  Chapter  III,  a  call  to  procedmre  S  is  defined  by  the  following  tuple. 


<C  ids  5  Pact  ^ 


In  order  to  differentiate  between  the  actual  parameters  that  are  input  parameters 
and  the  actual  parameters  that  are  output  parameters,  the  representation  of  a  procedure 
call  is  extended  as  follows.  Let  Pactin  represent  the  input  actual  parameters  and  let  Pactout 
represent  the  output  actual  parameters,  such  that  ®  Pactout  —  Pact-  The  procedure 
call  is  represented  by  the  following  tuple. 


<  ids )  Pactin  >  Pactout  ^ 


A  call  to  the  new  subprogram  Sp  is  represented  as  follows.  Let  PacUnp  represent  the 
input  actual  parameters  that  match  formal  parameters  from  the  new  subprogram.  Let  a 
represent  the  output  actual  parameter  that  corresponds  to  the  output  formal  parameter  p 
from  the  new  subprogram,  i.e.  /x(a)  =  p.  The  procedure  call  to  Sp  is  represented  by  the 
following  tuple. 

<  idsp  >  Pactinp  >  [®]  ^ 

6.12.1  Build  Slices  Transformation.  As  defined  in  Section  5.15,  the  first  step  in 
converting  Category  4  and  Category  5  subprograms  is  to  build  one  new  subprogram  for 
each  of  the  data  items  produced  by  the  Category  4  or  Category  5  subprograms.  This  section 
defines  the  formal  transformation  used  to  generate  the  program  slices  for  all  Category  4  and 
Category  5  subprograms.  Once  the  slices  are  built,  the  transformation  for  inter-procedural 
slicing  is  used  to  call  each  program  slice  as  needed.  That  transformation  is  also  defined  in 
this  section. 
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T^f'^iSD)  =  SD'  where 
For  each  S  £  SD 

S  =  <.  ids, Pin) P out,  [  ], Piocj^s  ^  and 
S  E  SD'  and 
Cat^lS)  or  Cat5(S) 

[V  p  6  Pout 

Sp  =  <.  idsp,  Pinp,  \p\,  [  ]) -f*/ocp)  ^(^s)  ^  and 

Sp  e  SD'  ] 

Figure  190  The  transformation 

Let  represent  the  transformation  that  builds  each  of  the  program  slices  for 

Category  4  and  Category  5  subprograms.  Let  SD  represent  a  collection  of  imperative 
subprograms.  Let  TiSp  represent  the  program  slice  generated  for  the  data  item  p  from  the 
subprogram  S.  The  Tp“*^^  transformation  is  defined  as  shown  in  Figure  190. 

This  transformation  generates  a  program  slice  for  each  output  parameter,  p,  of  Cate¬ 
gory  4  and  Category  5  subprograms.  Each  of  the  original  subprograms  is  included  in  SD', 
and  the  subprograms  built  from  the  program  slices  are  also  included.  The  next  step  is  to 
change  each  subprogram  call  to  a  Category  4  or  Category  5  subprogram  into  a  sequence 
of  calls  to  the  new  subprograms  built  from  its  program  slices. 

Let  Tpf^^  represent  the  transformation  that  builds  the  sequence  of  calls  to  the  new 
subprograms.  Let  SD  represent  a  collection  of  imperative  subprograms,  and  let  S  repre¬ 
sent  one  of  these  subprograms.  The  transformation  is  defined  in  Figure  191.  This 

transformation  creates  a  sequence  of  subprogram  calls,  Ls„  for  each  call  in  S  that  is  in¬ 
voking  a  Category  4  or  Category  5  subprogram.  The  Ls„  sequence  collects  the  calls  to 
the  new  subprograms  that  are  built  from  the  program  slices.  Each  data  item  in  5  that  is 
produced  from  the  Category  4  or  Category  5  subprogram  is  now  produced  in  S'  by  calling 
the  new  subprogram.  The  updated  subprogram.  S',  is  added  to  the  updated  design,  SD', 
which  is  returned  as  the  result  of  the  transformation. 
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T^f%SD,S)  =  SD' where 

5  =  <  ids  )  Pint  Pouti  Preti  Ploc,  S5  >  and 
VseSs 

S5  =  S51  0  [s]  0  E52  and 

S  =  <  ids^ ,  Pactin  5  Pactout  ^  ^ 

Sn  €  5D  and 

^  idSni  Pin^  Pout^\  jj-Pioo^Sn  ^  ClTld 

I  Pout  1^1^ 

V  p  €  fo«t 

“Sp  <  Piupi  [p])  [  ])  Plocpi  ^Sp  ^  and 
Sp  ^  SD'  and 

Lsn  ~  [^p  I  ~  )  Pactinp  >  [p]  ^  and 

Pactinp  =  [a  I  a  6  Pocti„  and 
b  €  PiTip  and  fi{a)  =  b]  and 

I  Pout  I  <=  1 

PSn  =  [s]  and 

Ti's  =  E^i  ©  Lsn  ©  E52  and 
S  ^  <  idSn  )  Pactin  )  Pactout  ^  ^ 

S5  =  S^i  ©  [s]  ©  S52  and 
S  =  <  idsi  Pirn  Pouti  Preti  Ploc^^S  ^  and 
SD'  =  T+{T-{SD,S),S') 

Figure  191  The  transformation 


233 


Let  represent  the  transformation  that  builds  all  the  program  slices  and  updates 

the  imperative  subprograms  to  call  the  program  slices  instead  of  the  Category  4  and 
Category  5  subprograms.  Let  SD  represent  a  collection  of  imperative  subprograms. 

T^^o.in(^SD)  =  SD"  where 
SD'  =  T^^^^SD)  and 
SD"  =  T^^^\SD',S) 

The  result  of  this  transformation  is  an  imperative  design  where  each  Category  4  and 
Category  5  subprogram  has  been  replaced  by  the  procedures  built  from  program  slicing 
the  subprogram.  Each  subprogram  in  this  design  is  updated  to  call  the  program  slices 
instead  of  the  Category  4  or  Category  5  subprogram. 

6. IS  Converting  an  Imperative  Design 

The  PBOI  method,  as  a  whole,  converts  a  collection  of  imperative  subprograms  into 
a  collection  of  classes  and  methods.  The  collection  of  imperative  subprograms  is  repre¬ 
sented  as  an  imperative  design,  and  the  collection  of  classes  and  methods  is  represented  as 
an  object-oriented  design.  The  conversion  of  the  imperative  design  begins  with  the  main 
program,  which  is  identified  by  the  user  (see  Assumption  V.l  in  Chapter  V).  The  trans¬ 
formation  that  formalizes  the  conversion  of  the  imperative  design  to  an  object-oriented 
design  is  the  ap  transformation.  This  transformation  is  defined  below. 

Let  SD  represent  an  imperative  design,  and  let  OOD  represent  an  object-oriented 
design.  The  ap  transformation  is  defined  as  follows. 

ap{SD)  —  OOD  where 

SD'  =  T^^{SD)  and 
M'  ^  SD'  and  CatM{M')  and 
OOD  = 

This  transformation  uses  the  transformation  to  build  a  new  imperative  design 

without  Category  4  or  Category  5  subprograms.  The  ctm  transformation  is  used  to  convert 
the  main  program  of  this  imperative  design.  The  result  of  this  transformation  is  the  object- 
oriented  design  OOD. 
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6.14.  Summary 

This  chapter  has  presented  transformations  that  formalize  the  conversion  of  imper¬ 
ative  statements,  expressions,  parameters,  attributes,  and  subprograms  using  the  PBOI 
method.  Section  6.1  provides  a  table  listing  the  transformations  that  are  presented  in  this 
chapter.  The  transformations  that  formalize  the  program  slicing  process  have  also  been 
presented  in  this  chapter.  Using  these  transformations,  a  collection  of  imperative  subpro¬ 
grams  can  be  converted  to  a  functionally  equivalent  collection  of  classes  and  methods  that 
implement  the  subprograms.  This  claim  is  discussed  and  proven  in  the  following  chapter. 
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VII.  Proving  Functional  Equivalence 

7. 1  Introduction 

In  order  to  evaluate  the  Object-Oriented  (OO)  design  that  is  extracted  using  the 
PBOI  methodology,  a  proof  is  developed  in  this  chapter  that  shows  the  extracted  OO  code 
(represented  in  the  GOM)  is  a  consistent  implementation  of  the  original  imperative  code 
(represented  in  the  GIM).  Given  the  same  input,  a  consistent  implementation  produces 
the  same  output  as  the  original  code.  To  build  this  proof,  the  behavior  of  both  the  original 
imperative  code  and  the  extracted  OO  code  are  defined. 

Let  F  be  the  original  imperative  code  as  represented  in  the  GIM.  Let  F'  be  the 
extracted  OO  code  as  represented  in  the  GOM.  One  undesirable  approach  for  showing  F' 
is  a  consistent  implementation  of  F  is  to  delineate  all  the  inputs  and  outputs  for  F  and 
show  that  an  input  given  to  F'  produces  the  same  output  as  F.  This  is  an  impractical 
approach  and  is  not  discussed  further.  At  the  highest  level,  F  represents  the  main  program 
from  the  imperative  design  and  F'  represents  the  main  method  from  the  object-oriented 
design.  The  transformation  that  converts  F  to  F'  is  the  ap  transformation,  i.e.  F'  = 
aF{F).  Since  the  semantics  of  both  F  and  F'  are  expressed  using  the  weakest  precondition 
notation,  the  proof  of  functional  equivalence  is  bcised  on  their  weakest  preconditions.  Given 
a  postcondition  R,  the  semantics  of  F  are  defined  as  follows. 

{  wp{F,  R)}F{R} 

Since  the  postcondition  and  weakest  precondition  are  predicates  (expressions)  defined  in 
terms  of  imperative  variables,  they  must  be  transformed  as  well.  The  9e  transformation 
built  to  convert  expressions  is  used  to  convert  these  predicates.  Hence,  the  semantics  of 
F'  are  defined  as  follows. 


{  wpiF',  OeiR)  }  F'  {  e,{R)  } 


If  it  can  be  proven  that  the  transformation  of  imperative  subprograms  is  a  mor¬ 
phism  [46] ,  it  can  be  proven  that  the  weakest  precondition  predicate  is  “preserved”  by  the 
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transformation.  If  this  can  be  proven,  then  the  semantics  for  the  imperative  subprograms 
are  equivalent  to  the  semantics  of  the  object-oriented  methods,  i.e.  they  are  functionally 
equivalent.  The  ap  transformation  is  a  morphism  if  the  following  equality  can  be  proven 
correct. 


eeiwp{F,  R))  wpiapiF),  0e{R)) 

The  rest  of  this  chapter  provides  lemmas,  theorems,  and  proofs  which  are  used  to 
prove  that  this  equality  holds.  Since  the  cxp  transformation  uses  several  other  transforma¬ 
tions,  proofs  are  presented  that  prove  these  transformations  maintain  functional  equiva¬ 
lence.  The  proofs  for  the  6  and  6  transformations  are  presented  first,  followed  by  proofs 
for  the  V  and  a  transformations.  The  proof  for  the  ap  transformation  is  presented  in 
Section  7.6,  at  the  end  of  the  chapter. 

7.2  Proof  for  Statement  Transformations  (6) 

The  6  transformation  is  used  to  convert  a  sequence  of  GIM  statements  to  a  se¬ 
quence  of  GOM  statements.  Theorems  are  presented  and  proven  below  showing  that  the  0 
transformation  of  assignment  statements,  input  statements,  output  statements,  sequential 
control  flow,  selective  control  flow,  and  iterative  control  flow  maintains  functional  equiva¬ 
lence.  Imperative  subprograms  and  subprogram  calls  are  not  transformed  by  0,  but  by  a 
and  V,  respectively.  The  proofs  for  a  and  v  appear  in  Section  7.4. 

Since  the  textual  substitution  [19]  notation,  R^,  is  used  for  defining  the  semantics  of 
assignment  statements,  the  following  lemma  is  provided  for  0g{R^). 

Lemma  VII.l.  0e{R^)  ^ 

Proof.  1.  The  notation  R^  symbolizes  the  simultaneous  replacement  of  all  free  occur¬ 
rences  of  X  with  e  in  the  predicate  R. 

2.  When  0^  is  applied  to  R^  on  the  left-hand-side  of  the  equality,  the  textual  substitution 
is  done  first  and  the  0e  transformation  is  applied  to  R  as  well  as  the  newly  substituted 
occurrences  of  e,  i.e.  0eie). 
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3.  When  the  6^  transformation  is  applied  to  R  on  the  right-hand-side  of  the  equality, 
the  occurrences  of  x  are  converted  using  6y{x)  so  the  substitution  in  9e{R)  works 
properly. 

4.  The  9e  transformation  is  applied  to  e  before  it  replaces  9y(x)  in  9e{R)  so  that  the  9e 
transformation  of  R  is  complete  after  the  substitution. 

5.  Thus,  on  both  sides  of  the  equality,  9e  is  applied  to  all  newly  substituted  occurrences 
of  e  in  R. 

□ 


7.2.1  Proof  for  Assignment  Statements.  The  following  theorem  is  proven  in 
order  to  shown  that  the  transformation  of  assignment  statements  preserves  functional 
equivalence. 

Theorem  VII.l.  The  9  transformation  o/ assignment  statements  in  the  GIM  preserves 
functional  equivalence. 


Proof. 

wp{9{<  X,  :=,  e  >),  9f.{R)) 

wp{<  9v(x),:=,9e(e)  >,  9e(R)) 

9e{Re)  by  Lemma  VII.l 
9e{wp{<  X,  :=,  e  >,  R)) 


□ 

7.2.2  Proof  for  Input  and  Output  Statements.  The  following  theorem  is  proven 
in  order  to  shown  that  the  transformation  of  input  statements  preserves  functional  equiv¬ 
alence.  The  proof  is  given  for  a  sequence  of  2  inputs.  The  extension  to  arbitrary  length 
sequences  is  obvious. 

Theorem  VII.2.  The  9  transformation  of  input  statements  in  the  GIM  preserves  func¬ 
tional  equivalence. 


238 


Proof. 


wp{9{<  input,  iport,  [?;i,  V2\  >),  0e{R)) 

wp{<  input,  iport,  0v([wi,  ^2])  >,  ^e{R)) 
wp{<  input,  iport,  [0t,(ui),  >>  ^e(-R))  ^ 

wp{[<  0„(t;i),:=,0e(a:i)  >,  <  0^{v‘i),‘=,^e{x2)  >],0e{R))  ^ 
wp{[<  Oy{vi),:=,ee{xi)  >,  0e(-R)5”(2) 


^eiiRlDll)  ^  by  Lemma  VII.1 


9e{wp{<vi,:=,xi>,  RID) 

9e{wp{<vi,:=,xi  >,  wp{<V2,:=,X2  >,  R))) 
9eiwp{[<vi,:=,xi>,  <V2,:=,X2  >],R))  ^ 
9e{wp{<  input,  iport,  [ui,  V2]  >,  R)) 


□ 

The  following  theorem  is  proven  in  order  to  shown  that  the  transformation  of  output 
statements  preserves  functional  equivalence. 

Theorem  VII.3.  The  9  transformation  of  output  statements  in  the  GIM  preserves  func¬ 
tional  equivalence. 

Proof. 

wp{9{<  output,  oport,  E  >),  9e(R)) 

wp(<  output,  oport,  9e{E)  >,  9e{R))  4^ 

9e{R)  ^ 

9e{wp{<  output,  oport,  E  >,  R)) 


□ 

7.2.3  Proof  for  Skip  Statement.  The  following  theorem  is  proven  in  order  to 
shown  that  the  transformation  of  skip  statements  preserves  functional  equivalence. 

Theorem  VII.4.  The  9  transformation  of  skip  statements  in  the  GIM  preserves  func¬ 
tional  equivalence.^ 

^  There  is  no  surface  syntax  defined  for  the  skip  statement. 
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Proof. 


wp{6{skip),  9e{R)) 

wp{skip,  Oe{R))  -O- 

de{R) 

6e(wp{skip,  R)) 


□ 

7.2.4  Proof  for  Sequential  Control  Flow.  The  following  theorem  is  proven  in 
order  to  shown  that  the  transformation  of  sequences  of  statements  preserves  functional 
equivalence. 

Theorem  VII.  5.  The  6  transformation  0/ sequential  control  flow  for  sequences  of  assign¬ 
ment,  input,  output,  and  skip  statements  preserves  functional  equivalence. 

Proof.  Since  it  has  already  been  proven  that  the  9  transformation  maintains  functional 
equivalence  for  the  assignment,  input,  output,  and  skip  statements,  the  following  equality 
holds. 


u;p(0([si,S2]),  9e(R))  4^ 

wp([9(si),9(s2)],  9e(R))  44 
wp(9(si),wp(9(s2),  9e{R)))  44 
wp{9{s]),9e{wp{s2,  R)))  44 
9e(wp(si,wp(s2,  R)))  44 
9e(wp([si,S2},R)) 


o 

7.2.5  Proof  for  Selective  Control  Flow.  This  section  provides  a  proof  showing  that 
the  9  transformation  of  selective  control  flow  statements  maintains  functional  equivalence. 
The  following  theorem  is  proven  below. 

Theorem  VII.6.  The  9  transformation  of  selective  control  flow  in  the  GIM  preserves 
functional  equivalence. 
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Proof  by  Induction.  1.  Base  Case:  The  proof  of  Theorem  VIL5  shows  that  6  maintains 
functional  equivalence  for  sequences  of  assignment,  input,  output,  or  skip  statements. 
Thus,  the  following  equality  holds. 


wp{0{<  if,  e,  then,  Si,  else,  >),  0e{R)) 

wp{<  if,  Oe{e),  then,  0(Si),  else,  0(82)  >),  6e{R))  ^ 

((0e(e)  ^  wp{e{Si\  OeiR)))  A  (-0e(e)  ^  wp{e{S2),  0e(i?))))  ^ 

((0e(e)  ^  e,{wp{Su  R)))  A  (-0e(e)  0e(w^p(52,  R))))  ^ 

{6e{{e  ^  wp{Si,  R)))  A9e{i-'e  wp{S2,  R)))) 

6e{{{e  ^  wp{Si,  R))  A  {-^e  wp{S2,  R)))) 

6e{wp(<  if,  e,  then.  Si,  else,  S2  >,  R)) 

2.  Inductive  Hypothesis:  Assume  the  sequences  of  statements  5i  and  82  also  include 
if-then-else  statements,  and  the  6  transformation  correctly  transforms  an  if-then-else 
statement  with  an  arbitrary  number,  n,  of  nested  if-then-else  statements. 

3.  Inductive  Step:  Prove  that  adding  the  n  -f  1  nested  if-then-else  statement  maintains 
the  functional  equivalence.  Since  this  new  nested  if-then-else  is  the  final  nested 
statement,  it  includes  only  assignment,  input,  output,  or  skip  statements  in  the 
sequences  Si  and  82-  The  functional  equivalence  is  maintained  for  this  statement  as 
shown  for  the  base  case. 

□ 

The  corollary  shown  below  follows  from  the  proof  that  the  9  transformation  of  the 
selective  statement  maintains  functional  equivalence. 

Corollary  VII.  1.  The  9  transformation  of  sequential  control  flow  for  sequences  of  assign¬ 
ment,  input,  output,  skip,  and  selective  statements  preserves  functional  equivalence. 

7.2. 6  Proof  for  Iterative  Control  Flow.  This  section  provides  a  proof  showing  that 
the  9  transformation  of  iterative  control  flow  statements  maintains  functional  equivalence. 

Theorem  VII. 7.  The  9  transformation  for  iterative  control  flow  in  the  GIM  preserves 
functional  equivalence. 
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Proof  by  Induction.  1.  Base  Case:  The  proof  of  Theorem  VIL5  shows  that  6  maintains 
functional  equivalence  for  sequences  of  assignment,  input,  output,  or  skip  statements. 
Thus,  the  equality  shown  in  Figure  192  holds. 

2.  Inductive  Hypothesis:  Assume  the  sequence  of  statements  S3  also  includes  while 
statements,  and  the  9  transformation  correctly  transforms  a  while  statement  with  an 
arbitrary  number,  n,  of  nested  while  statements. 

3.  Inductive  Step:  Prove  that  adding  the  n  +  1  nested  while  statement  maintains  func¬ 
tional  equivalence.  Since  this  new  nested  while  is  the  final  nested  statement,  it 
includes  only  assignment,  input,  output,  or  skip  statements  in  the  sequence  S3.  The 
functional  equivalence  is  maintained  for  this  statement  as  shown  for  the  base  case. 

□ 

The  corollary  shown  below  follows  firom  the  proof  that  the  transformation  of  iterative 
statements  maintains  functional  equivalence. 

Corollary  VII.2.  The  6  transformation  of  sequential  control  flow  for  sequences  of  assign¬ 
ment,  input,  output,  skip,  selective,  and  iterative  statements  preserves  functional  equiva¬ 
lence. 

Given  that  proofs  have  been  provided  for  selective  and  iterative  control  fiow,  the 
following  two  corollaries  follow  from  these  proofs. 

Corollary  VII.3.  The  6  transformation  of  selective  control  flow  for  sequences  of  assign¬ 
ment,  input,  output,  skip,  selective,  and  iterative  statements  preserves  functional  equiva¬ 
lence. 

Corollary  VII.4.  The  6  transformation  of  iterative  control  flow  for  sequences  of  assign¬ 
ment,  input,  output,  skip,  selective,  and  iterative  statements  preserves  functional  equiva¬ 
lence. 

Finally,  the  corollary  shown  below  follows  from  all  of  the  proofs  and  corollaries  pro¬ 
vided  for  the  6  transformation  to  this  point.  This  corollary  provides  an  assertion  that  the 
9  transformation  preserves  functional  equivalence  for  each  of  the  statements  defined  in  the 
GIM,  except  subprogram  definitions  and  calls. 
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wp{9{<  while,  e,  S3  >),  Oe(R)) 

wp{<  while,  0e(e),  OiSz)  >),  6e{R))  ^ 

wp{[<  if,  d^{e),  then,  6(83),  else,  0([sA:ip])  >,  iteration  1 

<  if,  6e{e),  then,  0(53),  else,  0([sfcip])  >,  iteration  2 

<  if,  0e(e),  then,  0(53),  else,  0([sHp])  >],0e(-R))  iteration  k 
wp{<  if,  0e(e),  then,  0(53),  else,  0([sfcip])  >,  iteration  1 

wp(<  if,  0e(e),  then,  0(53),  else,  6{[skip])  >,  iteration  2 

wp{<  if,  0e(e),  then,  0(53),  else,  0([sfcip])  >,  0e(-R))))  iteration  k 
wp{<  if,  0e(e),  then,  0(83),  else,  0([sfcip])  >,  iteration  1 

wp{<  if,  0e(e),  then,  9(83),  else,  9{[skip])  >,  iteration  2 

9e(wp{<  if,  e,  then,  S3,  else,  [sA:ip]  >,  R))))  iteration  k 
wp{<  if,  0e(e),  then,  0(53),  else,  0([sA:ip])  >,  iteration  1 
9e{wp{<  if,  e,  then,  S3,  else,  [sHp]  >,  iteration  2 

wp{<  if,  e,  then,  S3,  else,  [sfcip]  >,  R))))  iteration  k 
9e{wp{<  if,  e,  then,  S3,  else,  [sA:zp]  >,  iteration  1 
wp{<  if,  e,  then,  S3,  else,  [skip]  >,  iteration  2 

wp(<  if,  e,  then,  S3,  else,  [sfczp]  >,  R))))  iteration  k 
9e(wp{[<  if,  e,  then,  S3,  else,  [sfcip]  >,  iteration  1 

<  if,  e,  then,  S3,  else,  [sfeip]  >,  iteration  2 

<  if,  e,  then,  S3,  else,  [sHp]  >],  R))  iteration  k 
9g{wp{<  while,  e,  S3  >,  R)) 

Figure  192  Proof  for  iterative  base  case. 
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Corollary  VII.5.  The  6  transformation  of  sequences  of  assignment,  input,  output,  skip, 
selective,  and  iterative  statements  preserves  functional  equivalence. 

7.3  Proof  for  Parameters  and  Attributes  (6) 

This  section  presents  theorems  and  proofe  that  the  6  transformation  preserves  func¬ 
tional  equivalence.  This  transformation  is  used  by  the  a  transformation  when  GOM  pa¬ 
rameters  are  moved  to  attributes  and  vice  versa.  Since  the  6  transformation  converts 
accesses  of  GOM  variables  into  “GET-”  and  “SET-”  messages,  it  must  proven  that  an  ac¬ 
cess  to  variable  is  functionally  equivalent  to  a  “GET-”  message.  It  must  also  be  proven  that 
the  assignment  of  a  GOM  variable  is  functionally  equivalent  to  a  “SET-”  message.  These 
transformations  involve  only  GOM  entities,  so  there  is  no  need  to  convert  the  postcondition 
using  Og.  Let  R'  represent  a  postcondition  represented  using  GOM  variables. 

The  following  theorem  is  proven  below  in  order  to  show  that  the  6  transformation  of 
an  access  of  a  variable  into  a  “GET-”  message  preserves  functional  equivalence. 

Theorem  VII.8.  The  access  of  a  variable,  a,  in  a  statement  is  functionally  equivalent  to 
a  call  to  the  “GET-a”  message. 

As  an  example  of  this  theorem,  consider  the  expression  that  appears  on  the  right- 
hand-side  of  an  assignment  statement.  The  following  proof  shows  that  if  this  expression  is 
the  variable  a,  then  the  semantics  of  the  a.ssignment  statement  are  preserved. 
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Proof. 


w'p{8{[<  x' ,  :=,  a  >],c,  {a}),il') 
wp{<x',  :=,Se{a)>,  R')  ^ 
wp{<x',  :=,<  GET-a,  [c]>>,  R') 
wp{[y:=c.a,  b:-y,<x',  :=,6>],  R')  4^ 
wp{y  :=  c.a,wp{b  :=  y,wp{<  x',  :=,b>,  R')))  4^ 
wp{y  :=  c.a,wp{b  :=  y,  R'^  ))  O 
wp{y  :=  c.a,  {R'^  )J) 

((<)5)L  ^ 

R'ia  ^ 

R't  ^ 

wp(<x',  :=,a>,R') 


□ 

Other  examples  of  these  expressions  are  limited  to  the  expressions  that  appear  in  the 
boolean  tests  of  selective  and  iterative  statements.  Similar  arguments  are  made  for  these 
expressions,  so  in  general,  Theorem  VIL8  holds  for  any  statement  in  the  GOM. 

The  following  theorem  is  proven  below  in  order  to  show  that  the  6  transformation  of 
an  assignment  of  a  variable  into  a  “SET-”  message  preserves  functional  equivalence.  Let 
R'  represent  a  postcondition  represented  using  GOM  variables. 

Theorem  VII.9.  The  assignment  of  a  variable,  a,  is  functionally  equivalent  to  a  call  to 
the  “SET-a”  message. 

Proof. 

wp{6{[<a,  :=,e  >],c,{a}),  R')  44 
wp{<  SET-a,  [c,5e(e)]  >,  R')  44 

p/c.a 

^6e{e)  ^ 

R'Ue))  ^ 

wp{<  a,  :=,6e{e)  44 

wp{<  a,  :=,e  >,R')  from  Theorem  VII.8. 


□ 
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Similarly,  the  transformation  converts  an  access  of  a  specific  object  attribute 
into  an  access  of  a  GOM  variable.  Specifically,  each  “GET-a”  message  is  converted  into  a 
reference  to  the  variable  a,  and  each  “SET-a”  message  is  converted  into  an  assignment  to 
a.  The  following  theorem  is  proven  in  order  to  show  that  replacing  the  “GET-a”  message 
with  an  access  of  a  variable,  a,  in  an  expression  maintains  functional  equivalence.  Let  B! 
represent  a  postcondition  represented  using  GOM  variables. 

Theorem  VII.IO.  The  call  to  a  “GET-a”  message  in  a  statement  is  functionally  equiv¬ 
alent  to  the  access  of  the  variable,  a. 

As  an  example  of  this  theorem,  consider  the  expression  that  appears  on  the  right- 
hand-side  of  an  assignment  statement.  The  following  proof  shows  that  replacing  the 
“GET-a”  message  with  an  access  to  the  variable  a  maintains  the  functionality  of  the 
assignment  statement. 

Proof. 

wp{6~^{[<x,  :=,<  GET-a, [c]  >>], c, {a}), i?') 
wp{<  X,  :=,a>,  R!)  4^ 

K  ^ 

R'la  ^ 

wp(y:=c.a,  {R'tfy)  ^ 

wp{y  ■.=  c.a,wp{h  :=y,  R'l))  44- 

wp{y  :=  c.a,wp{b  ~  y,wp{<  X,  :=,b>,  R')))  4^ 

wp{[y  :=  c.a,  b:=y,<  x,  :=,  b  >],  R')  44^ 

wp{<  X,  :=,<  GET-a,  [c]>>,  R') 


□ 

Other  examples  of  these  expressions  are  limited  to  the  expressions  that  appear  in  the 
boolean  tests  of  selective  and  iterative  statements.  Similar  arguments  are  made  for  these 
expressions,  so  in  general.  Theorem  VII.IO  holds  for  any  statement  in  the  GIM. 

The  following  theorem  is  proven  in  order  to  show  that  replacing  the  “SET-a”  message 
with  an  assignment  of  a  variable,  a,  maintains  functional  equivalence.  Let  R'  represent  a 
postcondition  represented  using  GOM  variables. 
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Theorem  VII.ll.  The  “SET-a”  message  is  functionally  equivalent  to  an  assignment  of 
the  variable  a. 

Proof. 

wp{6~^(<  SET-a,  [c,  e]  >),  R') 
wp{<  a,  :=,e  >,  R') 

R'l  ^ 

R'l  ^^  ^ 

wp{<  SET-a,  [c,e]  >,  R') 


□ 


7.4  Proof  for  Subprogram  Conversion  (a) 

The  following  inductive  proof  shows  that  the  a  transformation  of  imperative  subpro¬ 
grams  whose  statements  also  include  procedure  calls  maintains  functional  equivalence. 

Theorem  VII.12.  The  a  transformation  of  imperative  subprograms  where  Es  is  com¬ 
prised  of  assignment,  input,  output,  skip,  selective,  and  iterative  statements,  as  well  as 
procedure  calls,  preserves  functional  equivalence. 

Proof  by  Induction.  1.  Base  Case:  The  a  transformation  of  a  subprogram  that  calls  a 
procedure  whose  S5  is  comprised  of  assignment,  input,  output,  skip,  selective,  and 
iterative  statements  preserves  functional  equivalence.  Using  Corollary  VII.5,  the  base 
case  is  proven  by  showing  the  Vm  transformation  of  such  a  call  preserves  functional 
equivalence. 
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ids  1  Pint  Pout  ^ 

wp{<  ids,  Sv{Pin),  ^viPout),  >,  ^e(-R))  ^ 
wp{[x  :=  0v (Pin),  (Pout)  •=  z],  ®e(-R)) 

wp{x  :=  ev{Pin),wpi0iSl),wp{ev{Pout)  '=  z,  0e{R))))  ^ 
wp{x  :=  ev{Pn),MO(Sl)MRf/^^°'‘'^))) 
wp{x  :=  ev(Pin),wp{0{Sl),ee{Ri°'‘^)))  O 
wp{x  ;=  0v(Pjn),^e(t«p('Sl,i?f"“‘))) 

6,{wp{SltR?r^)%^P,^^  ^ 

e,{wp{SltR?r^)%J  ^ 

6e{wp{x  PintWp{SltR?°'^*-)))  ^ 

6e{wp(x  :=  Pin,wp(Sl,wp{Pout  ■=  z,  R)))) 

Oei'^Pii^  •“  Pini^^iPout  •—  ^]>  -R))  ^ 

0ei'^Pi'‘^  Pin,}  Pout  R}} 

2.  Inductive  Hypothesis:  Assume  Us  of  the  called  procedure  also  includes  calls  to  other 
procedures.  Since  a  is  used  to  transform  these  called  procedures,  assume  that  the 
a  transformation  correctly  transforms  an  arbitrary  number,  n,  of  nested  procedure 
calls. 

3.  Inductive  Step:  Prove  that  adding  the  n+1  nested  procedure  call  maintains  functional 
equivalence.  Since  this  new  nested  procedure  call  is  the  final  nested  call,  it  includes 
only  assignment,  input,  output,  skip,  selective,  or  iterative  statements  in  S5.  The 
functional  equivalence  is  maintained  for  this  call  as  shown  for  the  base  case. 

□ 

Corollary  VII.6.  The  a  transformation  of  imperative  subprograms  where  E5  includes 
statements  with  expressions  that  include  function  calls  preserves  functional  equivalence. 

7.5  Proof  for  Program  Slicing 

This  section  presents  a  proof  that  the  7^“*”  transformation  preserves  functional 
equivalence.  This  transformation  builds  a  program  slice  for  each  data  item  being  produced 
from  a  Category  4  or  Category  5  subprogram  using  the  projection  function  tt.  The  col- 
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lection  of  program  slices  produced  duplicate  the  functionality  of  the  original  subprogram. 
This  is  expressed  formally  as  shown  below.  Let  S  represent  the  sequence  of  statement  from 
the  original  subprogram  which  produces  data  items  a  and  b. 

wpCE^R)  4^  «;p([7r(S,  a),  7r(S,  &)]) 

The  transformation  uses  the  Tpf'^  transformation  to  replace  each  call  to  a  Category 

4  or  Category  5  subprogram  with  a  sequence  of  calls  to  the  program  slices  built  for  the 
subprogram.  The  proof  of  the  following  theorem  shows  that  these  transformations  preserve 
functional  equivalence. 

Theorem  VII. 13.  The  transformation  of  GIM  subprograms  and  subprogram  calls  using 
the  transformation  preserves  functional  equivalence. 


Proof. 

wp{T^f^i[<ids,Pin,M>]),R) 
wp{[<  ids^, 

Pina  >  [a]  >,<ids^, 

Piubi  [6]  >],  R)  ^ 
wp{<  ids^,  Pinal  [a]  >,  wp{<  ids^, 

Pinbi  [6]  >,  R))  ^ 

wp{[Xa  • —  Pinal  7r(E,a),a  :=  z],  wp{[xb  • —  Pinbi  7r(S,6),6:=^],  R))  4^ 
wp(^Xa  ;=  Pina  >  ®'))  ®  • —  PiUb^  ^  •  ^]  >  P)  ^ 

u;p([5o  ;=  :=  Pi„(,,7r(S, a), a  :=  z,7r(E, 6), 6  :=  u],  R) 

t(;p([5a  ;=  Pm„,X6  Pmi,,7r(S,a),7r(S,6),a  :=  :=  v],  R)  4^ 

wp{[xa:=  PinaXb--=  Pinbhwpi[T^{'^,a),A'^,b)],wp{[a  :=  z,b:^v],  R))) 
wp{[x  :=  Pin],wp{'Es,wp{[a:=  z,b:=v],  R)))  44> 
wp{[x  :=  Pin,  S5,  a:=  z,b  :=  r],  R)  44> 
wp{<  ids,  Pin,  >,  R) 


□ 


7.6  Proof  for  Imperative  Design  (up) 

This  section  provides  a  proof  that  the  object-oriented  code  extracted  using  the  PBOI 
methodology  is  a  consistent  implementation  of  the  legacy  imperative  code.  As  discussed 
in  Section  7.1,  the  functionality  of  the  imperative  code  is  embodied  at  the  highest  level  in 
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the  main  program,  F.  The  functionality  of  the  object-oriented  code  is  embodied  at  the 
highest  level  in  the  main  method,  F'.  The  ap  transformation  is  used  to  transform  F  to 
F',  and  this  section  provides  a  proof  that  the  ap  transformation  produces  an  F'  that  is 
functionally  equivalent  to  F. 

Theorem  VII.14.  The  ap  transformation  preserves  functional  equivalence. 

Proof. 

wp(ap{F),eeiR))  ^ 

u;p(a(T“(^’)),  OeiR))  ^ 

e,{wp{T^^{F),  R))  ^ 

Se{wp(F,R)) 


□ 

Since  this  proof  shows  that  the  ap  transformation  preserves  functional  equivalence,  the 
object-oriented  design  extracted  using  the  PBOI  methodology  is  functionally  equivalent  to 
the  legacy  imperative  design. 

7. 7  Summary 

This  chapter  presented  several  definitions,  theorems,  and  proofs  in  order  to  show 
that  using  the  PBOI  methodology  results  in  an  object-oriented  design  which  is  a  consis¬ 
tent  implementation  of  the  original  imperative  design.  The  overall  functionality  of  the 
imperative  design  was  proven  to  be  maintained  in  the  extracted  object-oriented  design. 
This  was  done  by  proving  that  the  ap  transformation  preserves  functional  equivalence. 
The  following  chapter  presents  a  feasibility  demonstration  of  the  PBOI  methodology. 
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VIII.  Feasibility  Demonstration 


8.1  Introduction 

This  chapter  discusses  the  proof-of-concept  prototype  developed  to  implement  the 
PBOI  methodology.  As  a  feasibility  demonstration,  a  legacy  imperative  system  consisting 
of  over  3000  lines  of  FORTRAN-77  code  was  converted  to  the  object-oriented  paradigm. 
This  chapter  describes  the  transformations  used  to  convert  FORTRAN-77  code  to  the  GIM 
and  presents  a  summary  of  the  legacy  system  that  was  converted.  A  description  of  the 
extracted  object-oriented  design  is  presented  at  the  end  of  the  chapter. 

8.2  Converting  FORTRAN  to  the  GIM 

The  GIM  has  been  developed  in  order  to  provide  a  canonical  form  for  representing  im¬ 
perative  programming  languages.  As  a  proof-of-concept,  automatic  transformations  from 
FORTRAN-77  to  the  GIM  have  been  developed.  These  transformations  were  built  using 
the  Software  Refiner^^  development  environment.  The  Refine/FORTRAlfl'^  reverse 
engineering  tool,  part  of  Software  Refinery^ ^ ,  includes  a  domain  model  and  grammar  for 
FORTRAN-77.  Refine/FORTRAN  parses  in  FORTRAN  source  code  and  builds  Abstract 
Syntax  Trees  (ASTs)  that  store  information  about  the  source  code.  The  transformations 
build  new  GIM  ASTs  based  on  these  FORTRAN-77  ASTs. 

The  first  step  in  re-engineering  a  legacy  system  is  to  parse  each  subprogram  using 
Refine/FORTRAN^^.  Refine/FORTRAN^^  has  a  constraint  that  each  of  the  subpro¬ 
grams  must  reside  in  its  own  file,  and  the  files  to  be  parsed  are  collected  into  a  system. 
An  AST  is  built  for  the  system  and  each  AST  for  a  subprogram  is  part  of  this  AST.  After 
parsing,  the  system  AST  is  stored  in  one  file  called  the  analysis  file.  The  analysis  file  is 
loaded  into  the  re-engineering  prototype,  so  the  transformations  can  be  applied  to  each 
AST. 

A  typical  transformation  has  the  following  form. 

<  FORTRAN  AST  >  - >  <  GIM  AST  > 


251 


The  approach  taken  in  the  prototype  is  to  generate  a  new  GIM  AST  using  the  trans¬ 
formations,  as  opposed  to  transforming  the  existing  FORTRAN  ASTs.  This  means  as 
FORTRAN  ASTs  are  found  that  match  the  left-hand-side  of  the  transformation,  the 
GIM  AST  from  the  right-hand-side  of  the  transformation  is  built.  The  identifiers  on 
the  left-hand-side  indicate  ASTs  from  the  FORTRAN-77  domain  model  provided  in  the 
Refine/FORTRAN^^  User’s  Guide  [55]  and  the  identifiers  on  the  right-hand-side  indicate 
ASTs  from  the  GIM  domain  model  as  defined  in  Chapter  III.  All  of  the  transformations 
are  applied  to  each  node  in  the  FORTRAN  AST  by  using  the  REFINE  pre-order  traversal 
command.  The  traversal  begins  with  the  FORTRAN  AST  representing  the  overall  system. 

A  Refine/FORTRAN^^  workbench  has  been  built  that  displays  a  subprogram  from 
the  legacy  system  (using  the  FORTRAN-77  surface  syntax)  and  the  corresponding  sub¬ 
program  as  represented  in  the  GIM  (using  the  GIL  surface  syntax).  Figure  193  shows  this 
workbench.  The  upper-left  subwindow  of  the  workbench  shows  the  original  FORTRAN 
legacy  subroutine.  The  upper-right  subwindow  shows  the  GIM  representation  of  this  sub¬ 
routine.  The  two  subwindows  are  hyper-linked  to  show  the  connection  between  the  legacy 
FORTRAN  code  and  the  representation  of  the  code  in  the  GIM.  When  the  cursor  is  over  an 
AST  entity  in  the  GIL  Window,  the  surface  syntax  of  the  corresponding  FORTRAN  AST 
is  highlighted  in  the  Legacy  System  Window.  In  the  figure,  the  cursor  is  over  the  GIM 
addition  expression  R1  (2)  +  F  *  R2  (  2) ,  as  indicated  by  the  rubber-band  box.  The 
FORTRAN  AST  entity  from  which  this  expression  was  transformed  is  highlighted  in  the 
Legacy  System  Window  using  reverse  video.  Note  that  the  entire  FORTRAN  subroutine 
is  not  visible  in  the  upper-left  subwindow,  but  the  scroll  bar  can  be  used  to  view  the  rest  of 
the  subroutine.  The  workbench  also  shows  the  control  flow  graph  and  structure  chart  for 
the  VADD  subprogram.  The  structure  chart  is  provided  as  part  of  the  Refine/FORTRAN^^ 
workbench;  the  control  flow  graph  is  not. 

Because  of  the  limited  documentation  provided  with  Refine/FORTRAN^^,  it  was 
diflBcult  to  determine  the  attributes  of  an  AST  node  included  in  the  FORTRAN-77  do¬ 
main  model  without  parsing  a  statement  that  builds  the  node.  For  this  reason,  only  the 
transformations  that  were  needed  to  convert  the  selected  proof-of-concept  legacy  system 
were  developed  in  the  prototype. 
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Figure  193  FORTRAN  Workbench 
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Program  level  objects 

EXECUTABLE-PROGRAM 

PROGRAM-UNIT 

END-STATEMENT 

HEADER-STATEMENT 

PROGRAM-STATEMENT 

SUBROUTINE-STATEMENT 

PARAMETER _ 

Variables  object 

INDEXABLE-NAME 

IDENTIFIER 

IMPLICIT-STATEMENT 

TYPE-STATEMENT 

TYPE-BYTE 

TYPE-CHARACTER 

TYPE-DOUBLE-PRECISION 

TYPE-INTEGER 

TYPE-LOGICAL 

TYPE-REAL 

NAME-DECLARATOR 

POSSIBLY-INITIALIZED-NAME 

DIMENSION-DECLARATOR 

SIMPLE-LENGTH-DECL 

COMMON-DECLARATOR 

COMMON-STATEMENT 

EQUIVALENCE-DECLARATOR 

EQUIVALENCE-STATEMENT 

DIMENSION-STATEMENT 

RECORD- VAR-DECL 

STRUCT-REFERENCE 

STRUCT-ACCESS _ 

Table  2  Fortran  ASTs  Used 
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Expressions  objects 

ADD-EXPRESSION 

AND-EXPRESSION 

CONCATENATE-EXPRESSION 

DIVIDE-EXPRESSION 

EQ-EXPRESSION 

EQV-EXPRESSION 

EXPONENTIATE-EXPRESSION 

GE-EXPRESSION 

GT-EXPRESSION 

LE-EXPRESSION 

LT-EXPRESSION 

MULTIPLY-EXPRESSION 

NE-EXPRESSION 

NEQV-EXPRESSION 

OR-EXPRESSION 

SUBTRACT-EXPRESSION 

LITERAL-FALSE 

LITERAL-TRUE 

LITERAL-INTEGER 

LITERAL-RIGHT-TEXT 

LITERAL-DP 

LITERAL-REAL 

LITERAL-CHARSTRING 

LITERAL-HOLLERITH 

IDENTITY-EXPRESSION 

NEGATE-EXPRESSION 

NOT-EXPRESSION 

NULL-EX 

Assignment  objects 

ASSIGNMENT-STATEMENT 

PARAMETER-STATEMENT 

Control  flow  statement  objects 

CONTINUE-STATEMENT 

RETURN-STATEMENT 

INCLUDE-STATEMENT 

LABEL-DEFINITION 

LABEL-USE 

UNCONDITIONAL-GOTO 

CALL-STATEMENT 

BLOCK-IF-STATEMENT 

LOGICAL-IF-STATEMENT 

IF-THEN-ELSE-STATEMENT 

DO-STATEMENT 

Table  3  Fortran  ASTs  Used  (cont) 
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I/O  statements 

OPEN-STATEMENT 

READ-STATEMENT 

WRITE-STATEMENT 

PRINT-STATEMENT 

FORMAT-STATEMENT 

FORMAT-COMMA-SEPARATOR 

FORMAT-CLOSER 

UNIT-IDENTIFIER 

FORMAT-IDENTIFIER 

lO-FULL-SPECIFIER 

LIT-STRING-FORMAT 

FORMAT-SLASH-SEPARATOR 

FORMAT-DOUBLE-SLASH 

X-FORMAT 

I-FORMAT 

F-FORMAT 

E-FORMAT 

O-FORMAT 

Z-FORMAT 

R-FORMAT 

A-FORMAT 


Table  4  Fortran  ASTs  Used  (cont) 
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Table  2,  Table  3,  and  Table  4  show  the  domain  model  ASTs  that  are  included  in 
the  prototype.  The  other  ASTs  shown  in  Chapter  14  of  the  Refine/FORTRAN^^  User’s 
Guide  [54]  were  not  used.  A  separate  process  was  used  to  evaluate  the  completeness  of  the 
transformation  after  the  pre-order  traversal  process  completed  execution.  This  process  is 
described  in  detail  in  Section  8.3. 

The  following  sections  describe  the  transformations  that  have  been  developed  and  in¬ 
cluded  in  the  prototype.  These  transformations  convert  FORTRAN  statements,  variables, 
and  expressions  to  the  GIM. 

8.2.1  FORTRAN  Assignment  Statement  Transformation.  Variables  in  FOR¬ 
TRAN  are  assigned  values  using  the  assignment  statement  and  the  data  statement.  The 
transformation  of  these  two  statements  is  shown  in  Figure  194. 

assignment-statement  — y  imperative-assignment 
data-statement  — >  imperative-assignment 

Figure  194  Assignment  Transformations 

The  following  FORTRAN  assignment  statement  is  represented  using  the  FORTRAN 
assignment-statement  AST. 

RM  =  VMAG(R) 

The  variable  on  the  left-hand-side  of  this  assignment  is  converted  to  a  GIM  variable  and 
stored  in  the  left-hand-side  attribute  of  the  GIM  imperative-assignment  AST.  The  ex¬ 
pression  on  the  right-hand-side  of  this  assignment  is  converted  to  a  GIM  expression  and 
stored  in  the  right-hand-side  attribute  of  the  GIM  AST.  The  GIM  AST  built  from  this 
transformation  is  shown  below  using  GIL  syntax. 

RM  :=  VMAG  (  R) ; 

The  FORTRAN  AST  that  represents  the  following  DATA  statement  is  transformed  to 
the  GIM  by  building  two  imperative-assignment  ASTs. 

DATA  TW0PI/6.2831853072D0/  ,XMU/398601.2D0/ 
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Each  data  item  being  initialized  is  converted  to  a  GIM  variable  and  stored  in  the  left- 
hand-side  attribute  of  a  GIM  imperative-assignment  AST.  The  corresponding  value  for 
each  data  item  is  converted  to  a  GIM  expression  and  stored  as  the  right-hand-side  of  the 
assignment  statement.  The  two  GIM  assignment  statement  ASTs  generated  for  this  data 
statement  are  shown  below  using  GIL  syntax. 

TWOPI  :=  6.2831853072D0; 

XMU  :=  398601. 2D0; 

Because  of  the  syntactic  complexity  allowed  for  data  statements,  a  restriction  is  placed  on 
the  data  statements  that  are  transformed  using  the  prototype.  Specifically,  the  number 
of  the  data  elements  being  assigned  values  must  match  the  number  of  the  data  constants 
provided. 

8.2.2  FORTRAN  Sequential  Control  Flow  Transformation.  Sequential  control 
fiow  in  the  FORTRAN  AST  is  represented  by  storing  statements  in  sequences.  Sequences 
are  also  used  in  the  GIM  to  store  the  ASTs  built  from  the  transformation  of  these  state¬ 
ments.  Specifically,  statements  in  a  sequence  are  transformed  one  after  another  (sequen¬ 
tially),  and  the  corresponding  GIM  AST  built  from  the  transformation  is  appended  to  the 
corresponding  sequence  in  the  GIM.  Sequences  are  used  in  FORTRAN  ASTs  to  represent 
the  statements  in  subprograms,  if-then-else  statements,  and  looping  statements. 

8.2.3  FORTRAN  Selective  Control  Flow  Transformation.  Selective  control  flow 
in  the  FORTRAN  programming  language  is  implemented  by  the  if-then-else  statement, 
the  if-then  statement,  and  the  logical-if  statement.  Since  an  if-then  statement  is 
an  if-then-else  statement  without  an  else  part,  both  statements  are  represented  using 
the  REFINE/FORTRAN  block-if-statement  AST. 

Figure  195  shows  the  transformations  that  have  been  built  in  the  prototype  to  convert 
FORTRAN  selective  control  flow. 

For  example,  consider  the  following  FORTRAN  if-then-else  statement. 
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block-if-statement  — ^  imperative-selection 
logical-if-statement  — ^  imperative-selection 

Figure  195  Selective  Control  Flow  Transformations 


IF(ITYPE.LT.O)  THEN 

CALL  CSP(RT,RBO,TFBOT,XMU,VBOPP) 

ELSE 

CALL  CSP(RBa.RT,TFBOT,XMU,VBO) 

END  IF 

The  attributes  of  the  FORTRAN  block-if-statement  AST  that  represents  this  statement 

are  used  to  build  the  GIM  imperative-selection  AST  shown  below  (using  GIL  syntax). 

if  ITYPE  <  0  then 

CSP  (  RT,  RBO,  TFBOT,  XHU,  VBOPP) ; 
else 

CSP  (  RBO,  RT,  TFBOT,  XMU,  VBO) 
endif 

The  FORTRAN  expression  is  converted  to  a  GIM  expression  and  stored  as  the  expression 
of  the  imperative-selection  AST.  Each  statement  in  the  then  part  is  converted  and 
stored  in  the  then  part  of  the  imperative-selection  AST.  Each  statement  in  the  else 
part  is  also  converted  and  stored  in  the  else  part  of  the  imperative-selection  AST. 

The  transformation  of  the  FORTRAN  if-then  statement  is  only  slightly  different. 
The  following  statement  is  represented  using  the  FORTRAN  block-if-statement  AST. 

IF (THETA. GT. PI)  THEN 
ITYPE  =  -ABS( ITYPE) 

THETA  =  2.D0*PI  -  THETA 
END  IF 

In  this  case,  the  else  part  of  statement  is  empty,  which  is  represented  in  the  FORTRAN 
AST  as  an  empty  sequence.  The  expression  from  this  AST  is  converted  and  stored  as 
before,  and  the  statements  from  the  then  part  are  converted  and  stored.  The  empty  else 
part  of  this  statement  is  also  represented  as  an  empty  sequence  in  the  GIM  AST.  The  GIM 
AST  is  shown  below  using  GIL  syntax. 

if  THETA  >  PI  then 

ITYPE  :=  -ABS  (  ITYPE); 

THETA  :=  2.0d0  *  PI  -  THETA 
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else 
endif ; 

The  GIL  syntax  for  the  if-then  statement  is  not  like  the  FORTRAN  syntax  because 
the  GIL  syntax  includes  the  else  keyword  even  if  there  are  no  statements  in  the  else  part 
of  an  if-then-else  statement. 

The  FORTRAN  logical-if  statement  provides  a  short-hand  syntax  for  the  if-then 
statement.  The  following  statement  is  represented  using  the  FORTRAN  logical-if  AST. 

IFCALT.LT.O.)  ALT  =  0 

As  with  the  if-then  statement,  the  expression  is  converted  to  a  GIM  expression  and 

stored.  The  logical-if  always  includes  a  single  statement,  so  this  statement  is  converted 

and  stored  in  a  sequence  in  the  then  part  of  the  GIM  AST.  An  empty  sequence  is  stored 

in  the  else  part  of  the  AST  as  was  done  with  the  if-then  statement.  The  GIM  AST  is 

shown  below  using  GIL  syntax. 

if  ALT  <  0  then 
ALT  :=  0 
else 
endif ; 

The  FORTRAN  programming  language  also  provides  a  way  to  nest  if-then-else 

statements  together  into  one  statement.  For  example,  the  following  FORTRAN  statement 

is  represented  using  a  REFINE/FORTRAN  block-if-statement  AST. 

IF(ITYP.Eq.l)  THEN 

ALT  =  -5.71D0 

ELSE  IF(ITYP.EQ.2)  THEN 

ALT  =  -1.57D0 

ELSE  IFCITYP.EQ.S)  THEN 

ALT  =  -9.46D0 

END  IF 

Note  that  there  is  only  one  END  IF  keyword  even  though  there  are  multiple  IF  clauses 
in  this  statement.  In  the  AST,  the  ELSE  IF  branches  of  the  statement  are  collected  into 
a  sequence  of  block-if-statements.  Since  not  all  imperative  languages  provide  such  a 
way  to  nest  if-then-else  statements,  this  statement  is  transformed  into  an  equivalent 
collection  of  embedded  if-then-else  statements.  The  transformed  statement  is  shown 
below. 
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if  ITYP  =  1  then 
ALT  :=  -5.71d0; 
else 

if  ITYP  =  2  then 
ALT  :=  -1.57d0; 
else 

if  ITYP  =  3  then 
ALT  :=  -9.46d0; 
else 
endif 
endif 
endif ; 

At  the  top  level,  this  is  a  single  if-then-else  statement  with  a  second  if-then-else 
statement  embedded  in  the  else  clause.  A  third  if-then-else  statement  is  embedded  in 
the  else  clause  of  the  second  if-then-else  statement. 

Appendix  C  shows  a  proof  that  the  transformation  of  nested  if-then-else  state¬ 
ments  to  embedded  if-then-else  statements  maintains  the  functionality  of  the  original 
FORTRAN  statement. 

8.2.4  FORTRAN  Iterative  Control  Flow  Transformation.  Structured  iterative 
control  flow  in  the  FORTRAN  language  is  implemented  using  the  do  statement  and  the 
proper  combination  of  the  if-then  statement  and  the  goto  statement.  Let  represent 
the  transformation  that  only  builds  a  GIM  imperative-iteration  AST  if  this  proper 
combination  of  statements  is  used.  The  transformations  built  in  the  prototype  for  convert¬ 
ing  FORTRAN  iterative  control  flow  constructs  are  shown  in  Figure  196. 

do-statement  — >  imperative-iteration 
block-if-statement  imperative-iteration 

Figure  196  Iterative  Control  Flow  Transformations 

The  following  do  statement  is  represented  using  the  FORTRAN  do-statement  AST. 

DO  100  1=1,3 
U(I)  =  R(I)/RM 
100  CONTINUE 
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The  attributes  of  this  AST  are  used  to  build  the  GIM  imperative-iteration  AST  as 
follows.  The  label  100  is  used  to  indicate  syntactically  which  statements  will  be  iterated. 
The  FORTRAN  AST  has  an  attribute  that  stores  this  sequence  of  statements,  so  each 
statement  is  converted  to  the  GIM  and  stored  in  the  imperative-iteration  AST.  The 
loop  variable  syntax  1=1,3  is  represented  by  an  attribute  for  the  loop  variable,  the  initial 
value  and  the  final  value.  A  GIM  imperative-assignment  AST  is  generated  to  assign  the 
initial  value  to  the  loop  variable  and  is  returned  as  part  of  the  imperative-iteration 
AST  transformation.  This,  in  effect,  inserts  an  assignment  statement  into  the  sequence  of 
GIM  statements  right  before  the  imperative-iteration  statement.  The  expression  built 
for  the  GIM  imperative-iteration  AST  is  always  a  less-than-or-equal  expression  that 
tests  whether  the  loop  variable  is  less  than  or  equal  to  the  final  value.  The  transformed 
GIM  imperative-iteration  AST  is  shown  below  using  the  GIL  syntax. 

I  :=  1; 

while  I  <=  3  do 
begin 

U  (  I)  :=  R  (  I)  /  RM; 

I  :=  I  +  1 
end 

The  only  if-then  statements  transformed  into  imperative-iteration  ASTs  have 
a  single  goto  statement  as  the  last  statement  of  the  then  clause.  This  goto  statement 
must  cause  program  control  to  return  to  the  line  that  includes  the  if-then  statement.  For 
example,  the  following  if-then  statement  has  such  a  goto  statement. 

150  IF(C2.GT.1.0D0)  THEN 
E  =  E  -  DE 
DE  =  DE/2. 

E  =  E  +  DE 
Cl  =  l.ODO  -  Et<*2 
C2  =  C1/C2GAM 
GO  TO  150 
END  IF 

This  if-then  statement  is  transformed  into  the  following  GIM  iterative  statement. 
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while  C2  >  l.OdO  do  begin 
E  :=  E  -  DE; 

DE  :=  DE  /  2; 

E  :=  E  +  DE; 

Cl  :=  l.OdO  -  E'-2; 

C2  :=  Cl  /  C2GAM 
end; 

8.2.5  FORTRAN  Subprogram  Transformation.  Imperative  subprograms  are  im¬ 
plemented  in  the  FORTRAN  language  by  the  subroutine  statement  and  the  function 
statement.  Subroutines  are  invoked  using  the  FORTRAN  call  statement.  Functions  are 
invoked  by  using  the  function’s  identifier  in  an  expression.  Let  represent  the  trans¬ 
formation  that  only  builds  a  GIM  imp-function-call  AST  if  the  identifier  refers  to  a 
function  begin  invoked.  The  transformations  that  have  been  built  in  the  prototype  to 
convert  these  entities  are  shown  in  Figure  197. 


subroutine-statement 

function-statement 

call-statement 

identifier 


imperative-procedure 
imperative- function 
imp-procedure-call 
imp-function-call 


Figure  197  Subprogram  Transformations 


S  UBR  O  UTINE  VADD  (I0P,R1,R2,R3 ) 

INCLUDE  ’bdincl.f’ 

C 

C  THIS  ROUTINE  PERFORMS  VECTOR  ADDITION  FOR  THREE  DIMENSIONAL 
C  VECTORS 
C 

DIMENSION  R1(3),R2(3),R3(3) 

F  =  FLOAT(IOP) 

R3(l)  =  Rl(l)  -b  F*R2(1) 

R3(2)  =  Rl(2)  +  F*R2(2) 

R3(3)  =  Rl(3)  -H  F=t<R2(3) 

RETURN 

END 


Figure  198  FORTRAN  Subroutine  VADD 
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For  example,  Figure  198  shows  the  FORTRAN  subroutine  VADD.  The  attributes  of 
the  FORTRAN  AST  built  for  VADD  are  used  to  build  an  imperative-procedure  AST  in 
the  GIM  as  follows.  The  subroutine  identifier  is  converted  into  a  GIM  variable  and  stored 
as  the  identifier  of  the  imperative -procedure  AST.  The  formal  parameters  lOP,  Rl,  R2, 
R3  are  converted  into  GIM  variables  and  stored  (in  the  same  order)  in  the  sequence  of 
formal  parameters  for  the  GIM  AST.  Each  statement  from  the  subroutine  is  converted 
into  a  GIM  statement  and  stored  (in  the  same  order)  in  the  sequence  of  statements  for 
the  imperative-procedure  AST.  The  GIM  AST  built  from  this  transformation  is  shown 
below  using  GIL  syntax. 

procedure  VADD  (  lOP,  Rl,  R2,  R3  ) 
begin 

F  :=  FLOAT  (  lOP) ; 

R3  (  1)  ;=  Rl  (  1)  +  F  *  R2  (  1); 

R3  (  2)  :=  Rl  (  2)  +  F  *  R2  (  2); 

R3  (  3)  :=  Rl  (  3)  +  F  ♦  R2  (  3) 

end 

Note  that  the  comments  from  the  FORTRAN  subroutine  are  not  modeled  in  the  GIM  AST. 
There  is  a  attribute  in  the  REFINE/FORTRAN  AST  that  stores  the  comments  from  a 
subroutine,  but  no  attempt  is  made  in  this  research  to  carry  the  comments  forward.  The 
FORTRAN  call  statement  that  invokes  VADD  is  shown  below. 

CALL  VADD(-1,RB,R(1,J,K),RRB) 

The  call  identifier  from  the  FORTRAN  AST  is  converted  to  a  GIM  variable  and  stored 
as  the  identifier  of  the  imp-procedure-call  AST.  The  sequence  of  actual  parameters  is 
converted  to  a  sequence  of  GIM  variables  (with  the  same  order)  and  stored  as  the  actual 
parameters  in  the  GIM  AST.  Because  of  Restriction  III.3,  an  extra  step  is  performed  in  this 
transformation  to  ensure  all  actual  parameters  are  variables.  Specifically,  the  -1  parameter 
in  the  call  to  VADD  is  replaced  by  a  temporary  variable  and  an  assignment  statement  is 
inserted  before  the  call.  The  two  GIM  ASTs  built  from  this  transformation  are  shown 
below  using  GIL  syntax. 

TEMP-29  :=  -1; 

VADD  (  TEMP-29,  RB,  R  (  1,  J,  K),  RRB) ; 


264 


8.2.6  FORTRAN  Variable  Transformation.  Each  FORTRAN  variable  in  the 
legacy  system  must  be  converted  to  a  GIM  variable.  The  representation  of  variables  in 
the  GIM  consists  of  two  parts.  An  imperative-variable  AST  is  built  for  each  variable 
and  stored  in  the  Imperative  Symbol  Table  (1ST).  All  of  the  information  needed  to  build 
an  imperative-variable  is  taken  from  the  FORTRAN  symbol  table  generated  during 
compilation.  The  symbol  table  includes  the  variable’s  identifier,  scope,  data  type,  and  a 
constant  value  (if  any).  If  the  FORTRAN  variable  is  an  array,  the  indices  are  not  stored 
with  the  variable  since  the  entire  array  is  considered  one  variable. 

References  to  a  FORTRAN  variable  are  modeled  using  the  imperative -name  AST 
shown  in  Figure  199. 

imperative-name 

imp-scope :  symbol 

imp-identifier :  symbol 

imp-indices ;  seq(imperative-data-constmct) 

Figure  199  Imperative  Name  Class 

A  new  instance  of  this  class  is  built  for  each  reference  to  a  FORTRAN  variable.  If 
the  variable  is  an  array,  the  array  indices  are  converted  to  GIM  expressions  and  stored 
in  the  imperative-name  object.  When  a  FORTRAN  variable  is  transformed,  the  1ST  is 
checked  to  see  if  an  imperative-variable  AST  has  already  been  built  to  represent  the 
FORTRAN  variable.  If  not,  an  imperative-variable  is  built  and  stored  in  the  1ST. 

Using  the  imperative-name  AST  was  meant  to  simplify  the  process  of  representing 
variables.  However,  in  hind-sight,  it  is  just  as  easy  to  represent  each  FORTRAN  variable 
using  an  instance  of  the  imperative-variable  class.  The  only  difference  between  an 
imperative-name  AST  and  an  imperative-variable  AST  is  that  an  imperative-name 
doesn’t  store  the  data  type  and  an  imperative-variable  doesn’t  store  the  indices  of  an 
array  variable.  These  two  ASTs  should  be  combined  into  one. 

Because  of  the  information  provided  by  the  FORTRAN  symbol  table,  declarations 
of  variables  are  not  transformed  or  modeled  in  the  GIM.  This  means  FORTRAN  common 
statements  and  dimension  statements  have  no  corresponding  construct  in  the  GIM.  Since 
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there  is  no  modeling  of  variable  declarations  in  the  GIM,  a  system  built  to  convert  GIM 
ASTs  into  an  imperative  language  such  as  C  would  have  to  automatically  generate  the 
appropriate  declarations  for  each  variable  as  required  by  the  language.  There  is  no  surface 
syntax  provided  for  a  GIM  imperative-variable  ASTs,  only  imperative-name  ASTs. 

8.2.1  FORTRAN  Data  Types  Transformation.  The  transformations  built  to 
convert  FORTRAN  data  types  (except  implicit  types  and  built-in  types)  are  shown  in 
Figure  200. 


type-integer 

type-byte 

type-real 

type-double-precision 

type-logical 

type-character 

array-type 


— >  imperative-integer 
— >  imperative-integer 
— >  imperative-real 
— >  imperative-real 
— >  imperative-boolean 
— >  imperative-string 
— >  imperative-array 


Figure  200  Data  Type  Transformations 

For  implicit  types,  if  the  type-expr-name  attribute  of  the  type-expr-type  attribute  of  an 
implicit-type  FORTRAN  AST  equals  the  symbol  real,  then  an  imperative-real  GIM 
AST  is  built.  If  the  attribute  equals  the  symbol  integer,  an  imperative-integer  GIM 
AST  is  built.  Similarly,  if  the  type-expr-name  attribute  of  a  built-in-type  FORTRAN 
AST  equals  the  symbol  real,  then  an  imperative-real  GIM  AST  is  built.  If  the  attribute 
equals  the  symbol  integer,  an  imperative-integer  GIM  AST  is  built. 

8.2.8  FORTRAN  Expression  Transformation.  A  FORTRAN  expression  can  be 
either  a  variable,  a  binary  expression,  a  unary  expression,  or  a  literal  constant  value.  This 
section  describes  each  of  the  transformations  for  these  kinds  of  expressions.  The  trans¬ 
formation  of  a  variable  is  described  in  Section  8.2.6.  The  transformations  included  in 
the  prototype  for  FORTRAN  binary  expressions  are  shown  in  Figure  201.  The  trans¬ 
formations  built  to  convert  FORTRAN  unary  expressions  are  shown  in  Figure  202.  The 
transformations  built  to  convert  FORTRAN  literal  expressions  are  shown  in  Figure  203. 


266 


add-expression 
and-expression 
concatenate-expression 
divide-expression 
eq-expression 
eqv-expression 
exponentiate-expression 
ge-expression 
gt-expression 
le-expression 
It-expression 
multiply-expression 
ne-expression 
neqv-expression 
or-expression 
subtract-expression 

Figure  201  Binary  Expression  Transformations 

negate-expression  — >  imperative-negate 
not-expression  — >  imperative-not 
null-ex  — >  imperative-null 

Figure  202  Unary  Expression  Transformations 

8.2.9  FORTRAN  Input/Output  Transformation.  Input  is  implemented  in  the 
FORTRAN  language  by  the  read  statement.  Output  is  implemented  by  the  write  and 
format  statements.  The  transformations  built  in  the  prototype  to  convert  FORTRAN 
input  and  output  statements  are  shown  in  Figure  204. 

8.3  Completeness  of  the  Transformation 

Since  transformations  were  not  built  for  the  entire  domain  model  provided  by  RE¬ 
FINE/FORTRAN,  a  process  was  defined  to  assess  the  completeness  of  the  transformation. 
Specifically,  as  the  FORTRAN  AST  was  being  transformed,  each  transformation  set  a  flag 
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literal-false 

literal-true 

literal-hex 

literal-integer 

literal-octal 

literal-real 

literal-quad 

literal-double 

literal-charstring 

literal-hollerith 

literal-right-text 


imperative-literal-b  o  olean 
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Figure  203  Literal  Expression  Transformations 
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write-statement 
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imperative-input 

imperative-output 
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Figure  204  Input  and  Output  Transformations 

on  the  AST  node  being  transformed.  A  separate  traversal  of  the  FORTRAN  AST  examines 
each  node  and  report  any  nodes  not  transformed.  This  process  proved  to  be  quite  effective 
and  uncovered  problems  with  the  overall  transformation  that  were  easily  corrected.  An 
excerpt  from  the  transcript  generated  by  the  conversion  of  the  ANG  subprogram  is  shown 
below. 

Converting  "ANG"  to  the  GIM... 

No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete . 

Total  number  of  tree  nodes:  60 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 

Saving  to  pob . . . 

Saving  AST  and  Symbol  Table  in  file... 

Saving  surface  syntax  in  file... 
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This  transcript  reports  the  conversion  of  ANG  is  100%  complete.  There  are  60  tree  nodes  in 
the  ANG  FORTRAN  AST,  and  the  new  AST  is  saved  to  the  Persistent  Object  Base  (POB). 
The  complete  transcript  from  the  conversion  of  the  3000  line  FORTRAN-77  legacy  system 
is  shown  in  Appendix  E. 

8-4  The  Ballistic  Missile  Defense  Simulation  System 

The  legacy  imperative  system  that  was  selected  for  the  feasibility  demonstration  is 
the  Ballistic  Missile  Defense  Simulation  (BMDSIM)  system  [36].  This  system  consists  of 
53  subprograms  including  the  main  program,  BMDSIMl.  This  system  was  developed  for  use 
as  a  real  production  system  and  is  not  a  toy  system  developed  just  for  this  research. 

Table  5  and  Table  6  show  a  summary  of  these  subprograms.  The  type  of  subpro¬ 
gram  (function  or  procedure),  the  subprogram  identifier,  the  category^  into  which  this 
subprogram  is  classified,  and  the  set  of  data  items  produced  are  presented  in  the  table. 

Some  of  the  subprograms  in  BMDSIM  were  re-structured  to  eliminate  unstructured 
uses  of  GOTO  statements.  There  were  no  global  variables  in  the  system  and  none  of  the 
parameters  were  both  input  and  output  parameters.  The  RAND  function  had  an  output 
parameter,  so  the  function  was  converted  into  a  procedure  with  two  output  parameters. 

After  these  changes,  the  total  number  of  lines  of  code  was  3109. 

8.5  Eliminating  Category  4  o.nd  Category  5  subprograms 

As  described  in  Chapter  VI,  the  first  step  in  converting  a  legacy  system  is  to  eliminate 
the  Category  4  and  Category  5  subprograms  by  using  program  slicing.  Figure  205  shows 
how  the  original  53  subprograms  are  classified  according  to  the  taxonomy  of  subprograms. 
After  program  slicing,  the  BMDSIM  system  consisted  of  105  subprograms  including  the 
main  program.  Figure  205  also  shows  how  each  of  these  105  subprograms  are  classified. 

Tables  7,  8,  and  9  show  a  summary  of  the  new  subprograms  generated  by  program 
slicing.  The  tables  show  the  name  of  each  subprogram  in  BMDSIM.  For  any  Category  4  or 

^One  of  the  six  categories  from  the  taxonomy  of  imperative  subprograms  presented  in  Chapter  V. 
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Category 

Before  Slicing 

After  Slicing 

0 

0 

0 

1 

1 

2 

22 

52 

3 

8 

52 

4 

9 

0 

5 

13 

0 

Total 

53 

105 

Figure  205  Subprograms  Classified 


Category  5  subprogram,  the  names  of  the  new  subprograms  built  from  it  and  the  category 
of  the  new  subprogram  are  shown.  The  final  column  indicates  on  which  of  the  slices  the 
process  of  masking  had  to  be  used. 

8.6  Implementing  the  PBOI 

The  next  step  in  the  conversion  process  is  to  transform  the  subprograms  represented 
in  the  GIM  into  classes  and  methods  represented  in  the  GOM.  This  is  done  using  the  PBOI 
methodology  described  in  Chapter  V.  Each  of  the  PBOI  transformations  was  implemented 
in  the  prototype  using  the  REFINE  programming  language.  Every  attempt  was  made  to 
match  the  names  of  the  REFINE  functions  with  the  transformations  they  implement.  The 
mappings  from  GIM  AST  entities  to  GOM  AST  entities  are  shown  in  Appendix  F. 

A  Refine^^  workbench  has  been  built  that  displays  both  the  imperative  subpro¬ 
gram  (shown  using  GIL  syntax)  and  the  object-oriented  class  and  method  (shown  using 
GOL  syntax)  extracted  from  this  subprogram.  Figure  206  shows  an  example  of  this  work¬ 
bench.  The  upper-left  subwindow  of  the  workbench  shows  the  GIL  representation  of  the 
GIM  subprogram  being  transformed.  The  subprogram  is  transformed  manually  using  the 
sigma  option  (not  shown)  from  the  Transformations  menu.  Once  the  subprogram  is 
transformed,  the  upper-right  subwindow  displays  the  extracted  class  and  method.  The 
lower-left  subwindow  displays  the  object-oriented  design  (that  has  been  extracted  to  this 
point)  using  class  diagrams.  The  class  diagram  shows  a  class  as  a  box  displaying  the  name 
of  the  class,  the  name  of  its  methods,  and  the  name  and  type  of  its  attributes.  Finally, 
the  lower-right  subwindow  displays  the  AST  that  represents  the  overall  design.  The  GOM 
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Figure  206  GOM  Workbench 
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ASTs  shown  in  this  subwindow  are  hyper-linked  with  the  GOL  surface  syntax  shown  in 
the  upper-right  subwindow. 

Each  of  the  105  Category  2  and  Category  3  subprograms  from  the  BMDSIM  system 
was  converted  to  the  object-oriented  paradigm  using  the  prototype.  This  resulted  in  an 
object-oriented  design  with  104  classes  and  104  methods.  The  main  program  was  also 
converted  which  added  another  class  and  method  to  the  design. 

During  the  conversion  of  the  main  program,  770  create  messages  were  built  for  511 
distinct  object  instances.  After  removing  duplicate  objects,  109  create  messages  remained 
for  109  distinct  object  instances.  After  removing  overlapping  classes,  the  design  consisted 
of  43  classes.  Of  these  classes,  33  classes  had  only  one  method,  6  classes  had  between  2 
and  11  methods,  and  4  classes  had  between  29  and  47  methods. 

In  order  to  address  the  reasonableness  of  the  objects  being  extracted,  an  informal 
semantic  analysis  was  done.  The  comments  in  the  BMDSIM  system  were  examined  to 
develop  a  rudimentary  domain  model.  The  extracted  objects  were  compared  against  this 
domain  model  in  order  to  find  a  correlation  between  the  objects  and  a  semantic  entity  from 
the  domain.  This  analysis  found  that  the  extracted  objects  tended  to  contain  attributes  of 
a  single  domain  entity,  as  opposed  to  multiple  domain  entities.  The  number  of  attributes  in 
the  extracted  objects  tended  to  be  less  than  the  number  of  attributes  in  the  domain  entity. 
That  is,  the  extracted  objects  described  pieces  of  the  domain  entities.  This  could  be  due  to 
the  rudimentary  nature  of  the  domain  model  developed.  The  entire  methodology  described 
to  this  point  has  been  fully  automated.  To  add  semantics  to  the  extracted  objects  may 
require  a  cooperative  effort  involving  the  analyst.  Further  analysis  of  the  semantic  nature 
of  the  extracted  objects  is  left  as  future  research. 

8. 7  Analysis 

The  prototype  was  built  on  a  SUN  SPARC  5  workstation  with  128MB  of  memory. 
Using  the  prototype,  the  conversion  of  BMDSIM  to  the  GIM  takes  less  than  20  minutes 
and  the  elimination  of  Category  4  and  Category  5  subprograms  takes  approximately  one 
hour.  The  prototype  converts  GIM  subprograms  to  the  GOM  using  the  PBOI  methodology 
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(except  for  merging  overlapping  classes)  in  approximately  24  hours.  Merging  overlapping 
classes  using  the  prototype  requires  an  additional  12  hours.  Because  of  its  inefficiency, 
using  the  prototype  to  convert  millions  of  lines  of  imperative  code  is  not  feasible. 

8.8  Summary 

This  chapter  has  presented  the  results  of  the  feasibility  demonstration.  A  summary 
of  the  BMDSIM  system  and  its  subprograms  was  provided  along  with  the  subprograms  re¬ 
sulting  from  program  slicing.  The  specific  transformations  used  to  transform  FORTRAN 
to  the  GIM  were  described  in  this  chapter.  The  object-oriented  design  extracted  from 
BMDSIM  was  also  described.  This  transformation  of  BMDSIM  using  the  prototype  im¬ 
plementation  demonstrates  the  conversion  of  a  FORTRAN  system  to  an  object-oriented 
design  is  technically  feasible. 
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IX.  Contributions 


9. 1  Introduction 

This  chapter  lists  the  contributions  this  research  makes  to  the  field  of  re-engineering. 

9.2  Major  Contributions 

This  research  makes  the  following  major  contributions. 

1.  The  Generic  Imperative  Model  (GIM). 

2.  The  Generic  Object-Oriented  Design  Model  (GOM). 

3.  The  Parameter-Based  Object  Identification  (PBOI)  methodology. 

4.  The  transformations  that  formalize  the  PBOI  methodology. 

5.  A  proof  that  the  object-oriented  design  is  a  consistent  implementation  of  the  legacy 

code. 

The  GIM  is  significant  because  it  provides  a  canonical  form  for  imperative  program¬ 
ming  languages.  This  allows  legacy  code  that  does  the  same  to  look  the  same.  There 
are  several  advantages  to  using  the  GIM  in  this  research  or  other  research  involving  im¬ 
perative  programming  languages.  First,  the  GIM  is  programming  language  independent, 
which  means  the  representation  is  not  tied  to  one  specific  programming  language.  By  using 
the  GIM  in  the  prototype,  legacy  code  in  another  language  can  be  re-engineered  once  the 
transformations  from  that  language  to  the  GIM  are  developed.  In  this  way,  the  GIM  allows 
the  prototype  to  be  easily  extended  to  other  languages.  Second,  the  GIM  is  program  con¬ 
struct  independent.  This  allows  the  GIM  to  represent  imperative  control  flow  structures 
in  easily  understood  canonical  forms.  For  example,  there  are  many  programming  language 
implementations  of  the  selective  control  flow  construct  from  imperative  languages,  but  the 
GIM  is  able  to  represent  if-then  statements,  if-then-else  statements,  nested  and  embedded 
if-then-else  statements,  and  case  statements  using  a  single  control  flow  construct.  This 
greatly  simplifies  the  task  of  building  formal  transformations  and  prototypes  based  on  the 
GIM  constructs.  Third,  the  GIM  provides  constructs  for  representing  simulated  control 
flow  constructs  so  they  can  be  transformed  into  a  canonical  form.  For  example,  imperative 
iteration  can  be  simulated  with  an  if-then  statement  and  a  goto  statement.  This  simulated 
iteration  is  converted  into  a  GIM  iteration  construct,  which  simplifies  the  representation 
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of  the  imperative  code.  From  these  three  advantages,  it  is  clear  that  any  research  based  on 
the  GIM  is  simplified  because  the  number  of  imperative  programming  language  constructs 
to  consider  has  been  greatly  reduced.  Finally,  the  GIM  provides  a  formal  definition  of  each 
of  the  imperative  programming  language  constructs  based  on  the  weakest  precondition 
notation. 

The  GOM  is  an  important  contribution  because  it  provides  a  canonical  form  for 
object-oriented  programming  languages.  Much  like  the  GIM,  the  GOM  is  programming 
language  independent,  program  construct  independent,  and  recognizes  simulated  control 
flow  constructs.  The  GOM  has  been  built  primarily  as  a  tool  for  forward  engineering,  so 
it  provides  a  model  from  which  an  object-oriented  program  can  be  produced.  By  building 
transformations  from  the  GOM  to  a  specific  object-oriented  language,  the  programming 
constructs  that  best  implement  the  canonical  forms  from  the  GOM  can  be  used  to  generate 
the  object-oriented  program.  As  in  the  GIM,  any  research  based  on  the  GOM  is  simplified 
because  the  number  of  object-oriented  constructs  to  consider  is  reduced.  The  GOM  also 
provides  formal  definitions  for  object-oriented  constructs  including  classes,  objects,  meth¬ 
ods,  and  messages.  Defining  the  formal  semantics  of  these  constructs  using  the  weakest 
precondition  notation  is  original  research  in  this  field. 

The  PBOI  methodology  is  the  most  important  contribution  of  this  research  because  it 
provides  a  new  way  to  extract  objects  from  legacy  imperative  code.  There  have  been  other 
object  identification  methods  presented  in  the  literature  (see  Chapter  I),  but  the  PBOI 
methodology  results  in  an  object-oriented  design  that  is  a  consistent  implementation  of  the 
legacy  imperative  system.  Other  researchers  have  developed  systems  to  extract  functionally 
equivalent  objects,  but  these  researchers  do  not  provide  a  proof  of  this  claim.  The  object- 
oriented  design  extracted  using  the  PBOI  methodology  is  valuable  because  it  produces  the 
same  output  as  the  legacy  system  given  the  same  input.  The  PBOI  methodology  is  similar 
to  the  GBOI,  TBOI,  and  RBOI  methodologies  because  it  extracts  objects  from  legacy  code. 
The  PBOI  methodology  is  significantly  better  because  it  extracts  functionally  equivalent 
objects,  it  has  been  formalized  using  mathematical  transformations,  a  proof-of-concept 
prototype  implementation  has  been  developed,  and  it  has  been  demonstrated  on  a  (real 
world)  3000-line  FORTRAN  legacy  system. 
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Using  formal  transformations  to  define  the  PBOI  methodology  is  a  significant  con¬ 
tribution  because  it  casts  the  methodology  in  a  consistent,  unambiguous,  and  provably 
correct  form.  The  transformations  demonstrate  how  an  entire  methodology  for  converting 
imperative  subprograms  can  be  expressed  using  formal  methods.  The  transformations  are 
based  on  the  formal  definitions  of  imperative  subprograms,  subprogram  calls,  and  pro¬ 
gramming  statements,  which  are  minor  research  contributes  as  discussed  in  Section  9.3. 
Other  researchers  can  use  this  work  as  an  exemplar  of  how  to  express  the  transformation  of 
imperative  subprograms  using  the  power  of  formal  methods.  These  transformations  were 
fully  automated  using  the  Refine^^  programming  language,  as  described  in  Chapter  VIII. 

The  proof  that  the  PBOI  methodology  extracts  an  object-oriented  design  that  is  a 
consistent  implementation  of  the  legacy  imperative  code  is  a  significant  contribution  in 
the  area  of  re-engineering  because  it  is  the  first  such  proof.  Without  defining  any  of  the 
specific  input  or  output  values  from  the  legacy  imperative  code,  it  has  been  proven  that 
the  extracted  object-oriented  design  produces  the  same  output  as  the  legacy  imperative 
code  given  the  same  input.  This  means  it  is  not  necessary  to  implement  the  design  to 
prove  it  is  consistent  with  the  legacy  code.  The  proofs  of  the  individual  theorems  also 
provide  exemplars  of  how  to  prove  the  consistency  of  formal  transformations  using  weakest 
precondition  arguments. 

These  major  contributions  combine  to  provide  a  significant  advance  in  the  area  of 
re-engineering,  viz.  the  definition,  formalization,  proof,  and  automation  of  a  novel  method¬ 
ology  for  extracting  a  functionally  equivalent  object-oriented  design  from  legacy  imperative 
code.  The  minor  contributions  of  this  research  are  discussed  in  the  following  section. 

9.3  Minor  Contributions 

This  research  also  makes  the  following  minor  contributions. 

1.  A  taxonomy  of  imperative  subprograms. 

2.  The  formal  definitions  of  imperative  subprograms,  object-oriented  classes,  object- 

oriented  methods,  and  object-oriented  messages. 

3.  The  Generic  Imperative  Language  (GIL). 

4.  The  Generic  Object-Oriented  Language  (GOL). 
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5.  The  n  relation  that  links  actual  parameters  to  formal  parameters. 

6.  The  proof-of-concept  prototype  built  for  the  FORTRAN  language. 

The  taxonomy  of  imperative  subprograms  provides  a  meaningful  way  to  classify  any 
imperative  subprogram.  It  focuses  the  job  of  re-engineering  to  six  well  defined  categories. 
Other  research  on  imperative  subprograms  can  also  use  the  taxonomy  in  the  same  way. 
The  attributes  that  define  the  taxonomy  could  be  modified  to  reflect  different  aspects  of 
imperative  subprograms. 

The  formal  definitions  of  imperative  subprograms,  subprogram  calls,  statements, 
and  designs  presented  in  Chapter  III  are  a  consistent  and  unambiguous  representation 
of  imperative  programming  language  constructs.  They  provide  a  foundation  for  formal 
transformations  of  imperative  constructs  that  can  be  used  to  develop  new  transformations 
in  other  research.  The  formal  definitions  of  object-oriented  classes,  methods,  messages, 
statements,  and  designs  provide  a  consistent  and  unambiguous  representation  of  object- 
oriented  programming  language  constructs.  In  this  research,  these  definitions  provide  the 
representation  of  the  target  of  the  formal  transformations.  The  definitions  of  imperative 
and  object-oriented  constructs  are  used  extensively  in  the  proof  of  functional  equivalence. 
These  representations  simplify  the  proof  because  of  their  formal  nature. 

The  GIL  and  the  GOL  provide  a  surface  syntax  for  the  GIM  and  the  GOM,  respec¬ 
tively.  They  have  been  implemented  using  a  grammar  that  defines  the  surface  syntax;  of 
GIM  and  GOM  constructs.  The  GIL  and  the  GOL  demonstrate  the  use  of  a  surface  syntax 
as  a  convenient  user  interface  to  Abstract  Syntax  Ti-ees.  The  surface  syntax  defined  for 
the  GIM  and  the  GOM  provide  a  user-friendly  interface  to  the  entities  being  transformed. 
In  this  way,  the  GIL  and  GOM  are  intended  to  be  used  to  view  an  AST  that  has  already 
been  built.  Since  the  GIL  and  the  GOL  have  been  built  using  a  grammar,  they  can  also 
be  used  to  build  ASTs  using  the  syntax  of  the  grammar.  Implementing  and  testing  this 
aspect  of  these  languages  is  beyond  the  scope  of  this  research,  but  the  idea  of  defining  a 
generic  imperative  language  and  a  generic  object-oriented  language  is  appealing.  Building 
the  GIL  and  the  GOL  is  a  minor  contribution  that  can  be  used  as  a  stepping  stone  to 
future  research. 
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The  fi  relation  proved  to  an  invaluable  aid  in  the  formalization  of  subprogram  signa¬ 
tures.  The  transitive  closure  of  fi  is  an  effective  way  to  determine  which  actual  parameter  is 
linked  to  a  formal  parameter  that  has  been  converted  to  an  attribute  of  a  class.  It  may  be 
possible  to  apply  this  relation  to  other  applications  that  update  signatures  of  subprograms. 

Finally,  the  proof-of-concept  prototype  demonstrates  that  legacy  systems  written  in 
FORTRAN-77  can  be  converted  to  the  GIM.  It  also  shows  that  the  entire  PBOI  methodol¬ 
ogy  can  be  automated.  The  transformations  that  define  the  PBOI  were  easily  implemented 
using  the  REFINE^^  programming  language,  which  demonstrates  the  utility  of  such  for¬ 
mal  definitions  and  languages  such  as  REFINE. 

These  minor  contributions  aided  this  research  in  achieving  the  overall  goal  of  ex¬ 
tracting  functionally  equivalent  object-oriented  designs  from  imperative  legacy  code.  The 
items  identified  for  future  research  are  discussed  in  the  following  section. 

9.4  Summary 

This  chapter  has  explained  why  the  GIM,  the  GOM,  the  PBOI  methodology,  and 
the  formal  transformations  are  significant  contributions  to  the  field  of  re-engineering.  The 
following  chapter  discusses  future  research  and  overall  conclusions. 
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X.  Future  Research  and  Conclusions 

10.1  Introduction 

This  chapter  summarizes  several  ideas  for  future  research  that  could  easily  extend 
this  research.  Concluding  remarks  are  included  at  the  end  of  this  chapter. 

10.2  Future  Research 

The  following  sections  discuss  items  that  should  be  done  as  future  research. 

10.2.1  Data  dependencies.  The  PBOI  methodology  may  be  too  aggressive  when 
determining  which  parameters  should  be  attributes  of  classes.  Specifically,  PBOI  Case  3 
should  be  scrutinized  and  possibly  extended  as  follows.  It  may  be  the  case  that  a  local 
variable  is  directly  data  dependent  on  an  input  parameter  of  a  Category  3  subprogram. 
When  this  local  variable  is  passed  as  a  parameter  to  another  subprogram,  it  will  not 
remain  as  an  attribute  of  a  class.  This  is  because  it  is  a  local  variable. 

However,  it  may  be  possible  to  extract  more  semantically  meaningful  objects  by 
allowing  the  data  item  linked  to  this  local  variable  to  remain  an  attribute  of  a  class.  This 
is  based  on  the  local  variable’s  data  dependency  to  the  formal  parameter.  There  are  three 
dependency  cases  to  consider. 

direct  One  or  multiple  assignment  statements  link  the  local  variable  back  to  the  formal 
parameter. 

indirect  The  local  variable  is  produced  from  a  subprogram  call  that  includes  the  formal 
parameter  as  an  input  parameter. 

hybrid  A  combination  of  both  direct  and  indirect  data  dependencies. 

An  issue  remains  as  to  which  data  item  should  be  built  as  the  attribute  of  the  class. 
Is  the  formal  parameter  of  the  called  subprogram  the  attribute  or  a  different  view  of  the 
attribute?  Is  the  formal  parameter  of  the  calling  subprogram  the  attribute?  Where  should 
the  code  that  changes  the  formal  parameter  into  the  local  variable  be  placed  as  a  method? 
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10.2.2  Arrays.  Arrays  present  an  interesting  challenge.  There  are  several  things 
that  have  been  left  as  future  research.  Specifically,  a  common  method  for  storing  data  in 
the  imperative  paradigm  is  to  build  parallel  arrays  of  data.  It  has  been  proposed  that  the 
attributes  of  a  candidate  object  can  be  derived  from  the  arrays  because  the  values  of  the 
attributes  of  a  single  instance  are  stored  at  the  same  index  in  the  arrays.  Future  research 
should  convert  these  parallel  arrays  of  attributes  into  a  single  array  of  instances  with  the 
appropriate  attributes. 

Another  popular  method  for  storing  homogeneous  attributes  of  candidate  objects  is 
to  use  a  single  array  to  represent  all  the  attributes.  A  second  array  or  another  dimension 
of  the  array  is  used  to  store  the  instances  of  the  objects.  These  arrays  of  attributes  could 
be  converted  into  parallel  arrays  of  attributes  and  then  converted  into  a  single  array  of 
objects  with  attributes. 

10.2.3  Modifying  the  Design.  The  process  of  merging  overlapping  classes  based 
on  the  overlap  of  a  single  data  item  may  be  too  aggressive.  As  described  in  the  Feasibility 
Demonstration  (see  Chapter  VIII),  the  design  extracted  for  the  BMDSIM  legacy  system 
included  classes  with  large  numbers  of  attributes  and  methods.  Future  research  should 
explore  different  heuristics  for  the  updates  done  to  the  design  when  the  main  program  is 
being  transformed. 

One  possibility  is  to  merge  two  classes  only  when  the  attributes  of  one  class  are  a 
subset  of  the  attributes  of  the  other  class.  This  is  a  more  restrictive  heuristic  for  merging 
that  may  avoid  building  classes  with  such  large  numbers  of  attributes  and  methods.  This 
may  introduce  duplication  of  system  state  variables,  however,  so  a  method  for  combining 
these  classes  without  duplicating  the  imperative  state  variables  must  be  developed.  One 
possibility  is  to  change  attributes  not  in  the  intersection  into  parameters  in  the  methods 
of  the  effected  classes. 

Another  issue  is  the  lack  of  analysis  that  is  done  on  the  subprograms  that  are  called  by 
the  main  program.  The  formal  parameters  of  these  subprograms  are  built  as  attributes  of 
classes,  but  there  is  no  filtering  of  these  data  items  to  see  if  they  should  remain  as  attributes. 
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It  may  be  the  case  that  changing  one  or  more  of  these  attributes  into  a  parameter  helps 
to  avoid  the  problem  of  building  classes  with  large  numbers  of  attributes  and  methods. 

During  the  conversion  of  the  BMDSIM  legacy  system,  several  classes  in  the  extracted 
design  included  no  attributes.  Future  research  could  examine  these  classes  and  possibly 
merge  them  into  one  utility  class.  There  appears  to  be  a  difference  between  a  class  where 
the  attributes  have  been  converted  solely  into  attributes  of  other  classes  and  a  class  where 
the  attributes  have  been  converted  solely  into  parameters. 

Currently,  object  instances  are  built  only  when  the  main  program  is  being  converted. 
It  is  possible  to  recognize  that  some  collection  of  local  variables  in  a  subprogram  actually 
represent  an  object  and  the  object  can  be  instantiated  at  the  correct  point  in  the  subpro¬ 
gram.  This  might  improve  the  prospects  of  identifying  more  “meaningful”  objects  from 
the  GIM. 

Finally,  in  order  to  add  semantics  to  the  extracted  objects,  some  interaction  with 
the  user  may  be  required.  An  extension  to  the  prototype  could  include  this  interaction 
to  determine  if  extracted  objects  should  be  combined  to  more  closely  resemble  domain 
entities.  If  domain  entities  are  expressed  formally,  it  may  be  possible  for  the  computer  to 
compare  the  domain  entities  to  the  extracted  objects. 

10.2.4  Program  Slices.  The  program  slicing  done  to  eliminate  Category  4  and 
Category  5  subprograms  produces  inefficient  slices.  Future  research  could  explore  ways  to 
optimize  these  slices  and  produce  less  conservative  slices.  Similarly,  some  of  the  program 
slices  that  are  built  during  this  process  are  repeated  in  whole  as  part  of  another  program 
slice.  Such  slices  could  be  built  as  object  methods  and  called  by  the  encompassing  program 
slice.  Finally,  the  same  imperative  output  statement  may  appear  in  multiple  slices  which 
may  cause  spurious  output  when  the  design  is  finally  implemented  and  executed.  A  more 
detailed  analysis  of  the  variables  being  output  could  be  done  as  future  research  in  order  to 
ensure  the  same  output  statement  does  not  appear  in  multiple  slices. 

10.2.5  The  Generic  Unstructured  Model.  It  may  be  possible  to  add  a  front-end 
to  the  reverse  engineering  methodology  that  automatically  re-structures  imperative  code. 


286 


Unstructured  legacy  code  could  be  transformed  into  a  canonical  form,  (termed  the  Generic 
Unstructured  Model  (GUM))  that  models  the  unstructured  use  of  goto  statements.  The 
transformation  of  GUM  entities  to  GIM  entities  would  provide  a  canonical  means  for  re¬ 
structuring  legacy  imperative  systems. 

10.2.6  Extensions.  Currently,  the  prototype  transforms  only  FORTRAN-77  to 
the  GIM.  Future  research  should  explore  the  conversion  of  other  imperative  languages  to 
the  GIM.  Reasoning  Systems^^  currently  provides  language  tools  only  for  FORTRAN,  C, 
Cobol,  and  Ada,  which  restricts  the  extension  of  the  prototype  to  these  languages  until 
parsers  for  other  languages  can  be  built.  Some  prototype  transformations  have  been  done 
for  Ada  83.  Specifically,  four  different  forms  of  iteration  in  Ada  have  been  canonicalized  into 
one  representation  in  the  GIM.  To  extend  the  GIM  further,  other  imperative  entities  such 
as  heterogeneous  data  types  and  pointers  could  be  added  to  the  GIM.  If  larger  systems  with 
millions  of  lines  of  imperative  code  are  to  be  transformed,  the  efficiency  of  the  prototype 
must  be  improved. 

10.3  Conclusions 

It  is  clear  that  this  research  has  been  completed  successfully.  The  objectives  defined 
in  the  Problem  Statement  (see  Chapter  II)  have  been  met.  The  GIM  provides  the  desired 
canonical  form  for  re-engineering  legacy  imperative  code,  as  presented  in  Chapter  III. 
The  GOM  provides  the  desired  canonical  form  for  the  object-oriented  target  system,  as 
presented  in  Chapter  IV.  Several  in-depth  examples  of  how  the  PBOI  methodology  ex¬ 
tracts  objects  from  GIM  subprograms  were  presented  in  Chapter  V.  The  PBOI  formal 
transformations  presented  in  Chapter  VI  define  the  PBOI  methodology  in  an  unambigu¬ 
ous,  consistent,  and  provably  correct  manner.  Using  the  PBOI  methodology  is  desirable 
because  the  extracted  object-oriented  design  is  functionally  equivalent  to  the  legacy  im¬ 
perative  code.  The  proof  of  this  claim  was  presented  in  Chapter  VII.  It  is  feasible  to 
automate  this  methodology  as  demonstrated  in  Chapter  VIII.  It  should  be  clear  to  the 
reader  that  this  research  makes  significant  contributions  to  the  field  of  re-engineering. 
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Appendix  A.  The  Generic  Imperative  Language 

A.l  Introduction 

This  appendix  includes  the  surface  syntax  developed  for  the  Generic  Imperative 
Language  (GIL^).  The  surface  syntax  provides  an  easy  way  to  view  the  GIM  representation 
of  an  imperative  program.  The  GIL  is  not  intended  to  be  used  as  a  forward-engineering 
programming  language. 

The  notation  used  to  present  the  surface  syntax  is  taken  from  the  Software  Refinery^^ 
Dialect  tool  [53].  Each  production  for  producing  surface  syntax  is  presented  using  the  fol¬ 
lowing  format: 

<GIM  object>  ::=  [  <surface  syntax  constructs>  ] 

The  left-hand-side  of  this  production  gives  the  GIM  object  for  which  this  surface  syntax 

is  defined,  and  the  right-hand-side  shows  the  sequence  of  constructs  used  to  define  the 

surface  syntax.  This  sequence  can  include  attributes  of  the  object  or  literal  syntax  tokens. 

Optional  constructs  are  enclosed  in  braces,  i.e.  {  }.  Sequences  of  constructs  are  indicated 

by  listing  an  attribute  of  the  object  followed  by  a  star  token  (*)  or  plus  token  (-f)  followed 

by  the  delimiter  token.  The  star  token  indicates  zero  or  more  members  of  the  sequence 

and  plus  token  indicates  one  or  more  members.  For  example,  the  surface  syntax  for  GIM 

imperative-name  objects  is  shown  below. 

imperative-name  ::=  [imp-identifier  !!  imp-has-indices 
"("  imp-indices  +  ")"] 

builds  imperative-name , 

This  production  means  the  surface  syntax  for  an  imperative-name  is  the  value  of  the 
imp-identifier  attribute  followed  by  any  indices  in  the  imp-indices  attribute  separated 
by  commas.  The  imp-has-indices  attribute  is  a  boolean  attribute  used  to  determine  if 
the  imperative-name  is  an  array  being  accessed. 

A. 2  The  Generic  Imperative  Language 

The  productions  that  define  the  GIL  grammar  are  presented  below. 

^Pronounced  “Jill”,  as  in  Jack  and  Jill. 
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! !  in-package ("RU") 

!!  in-grammar  ( ’syntaix) 

grammar  Generic-Imperative-Language 

file-classes  imperative-subprogram 

productions 

X - 

■/,  imperative  design 

I - 


imperative-design  ::=  [imperative-programs  + 
builds  imperative-design, 


•/. - 

*/,  data  types 

•/. - 


imperative-integer  : :=  ["integer"] 
builds  imperative-integer, 

imperative-real  : :=  ["real"] 
builds  imperative-real, 

imperative-boolean  ::=  ["boolean"] 
builds  imperative-boolean, 

imperative-character  ::=  ["character"] 
builds  imperative-character, 

imperative-string  ::=  ["string"] 
builds  imperative-string, 

imperative-array  ::=  ["array"  "("  imp-array-dimensions  *  ")" 

"of"  imp-array-element-type  ] 
builds  imperative-array, 

imperative-index-type  ::=  [imp-index-lower-bound  imp-index-upper-bound] 

builds  imperative-index-type. 


I - 

7,  variables  and  names 

I - 


imperative-name  ::=  [imp- identifier  "!!  imp-has-indices] 
builds  imperative-name, 

imperative-name  : :=  [imp-identifier  !!  imp-has-indices 
"("  imp-indices  +  ","  ")"] 
builds  imperative-name, 

X - 

7,  binary  expressions 

I - 
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imperative-addition  ::=  [imp-bin-exp-seq  ++  "+"] 
builds  imperative-addition, 

imperative-and  ::=  [imp-bin-exp-seq  ++  "and"] 
builds  imperative-and, 

imperative-concat  : :=  [imp-bin-exp-seq  ++  "ft"] 
builds  imperative-concat, 

imperative-division  ::=  [imp-bin-exp-seq  ++  "/"] 
builds  imperative-division, 

imperative-equal  : :=  [imp-bin-exp-operand-1  "="  imp-bin-exp-operand-2] 
builds  imperative-equal, 

imperative-exponent  ::=  [imp-bin-exp-operand-1  "“"  imp-bin-exp-operand-2] 
builds  imperative-exponent, 

imperative-greater-than-or-equal  : ;=  [imp-bin-exp-operand-l  ">="  imp-bin-exp-operand-2] 
builds  imperative-greater-than-or-equal, 

imperative-greater-than  : :=  [imp-bin-exp-operand-l  ">"  imp-bin-exp-operand-2] 
builds  imperative-greater-than, 

imperative-less-than-or-equal  ;:=  [imp-bin-exp-opereoid-l  "<="  imp~bin-exp-operand-2] 
builds  imperative-less-than-or-equal , 

imperative-less-than  [imp-bin-exp-operand-l  "<"  imp-bin-exp-operand-2] 
builds  imperative-less-than, 

imperative-multiplication  ::=  [imp-bin-exp-seq  ++  "*"] 
builds  imperat ive-mult iplicat ion , 

imperative-not-equal  ::=  [imp-bin-exp-operand-l  "/="  imp-bin-exp-opereuid-2] 
builds  imperative-not-equal, 

imperative-or  ::=  [imp-bin-exp-seq  ++  "or"] 
builds  imperative-or, 

imperative-subtraction  ::=  [imp-bin-exp-seq  ++  "-"] 
builds  imperative-subtraction. 


>1^ - 

uneory  expressions 

5^ - 


imperat ive-negate  ::=  ["-"  irap-unary-operand] 
builds  imperat ive-negat e , 

imperat ive-not  ;:=  ["not"  imp-unary-operand] 
builds  imperative-not, 

imperative-null  ::=  ["  "] 
builds  imperative-null. 
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•/. - 

*/,  literals 

•/. - 


imperative-literal-true  ::=  "true” 
builds  imperative-literal-true, 

imperative-literal-false  ::=  "false" 
builds  imperative-literal-false, 

imperative-literal-integer  ::=  imperative-literal-value 
builds  imperative-literal-integer, 

imperative-literal-real  ;:=  imperative-literal-value 
builds  imperative-literal-real, 

imperative-literal-charstring  ::=  imperative-literal-value 
builds  imperative-literal-charstring, 

imperative-literal-newline  ::=  "**/," 
builds  imperative-literal-newline , 


•/. - 

y.  assignment 

•/. - 


imperative-assignment  ;:=  [imp-assign-lhs  imp-assign-rhs] 

builds  imperative-assignment. 


y. - 

y,  selection 
% - 


imperative-selection  ::=  ["if"  imperative-exp  "then" 

imperative-then-part  +  " ; " 
"else" 

imperative-else-peurt  +  ";" 
"endif"] 

builds  imperative-selection. 


y. - 

y,  iteration 

y. - 


imperative-iteration  ::=  ["while"  iter-exp  "do" 

["begin" 

iter-body  + 
"end"] 

] 

builds  imperative-iteration, 

% - 

y,  imperative  subprograms 

X - 


imperative-procedure  : :=  ["procedure"  imp-proc-identif ier 


291 


] 


"("  imp-proc-formals  ♦  ")" 

["begin" 

imp-proc-statements  +  " ; " 
"end"] 


builds  imperative-procedure, 

imp-procedure-call  : : =  [  imp-proc-call-identif ier 

"("  imp-proc-call-actuals  ♦  ")"  ] 

builds  imp-procedure-call, 

imperative-function  ::=  [imp-function-retum-type  "function"  imp-func-identif ier 

"("  imp-func-f ormals  ♦  ","  ")" 

["begin" 

imp-f unc-statements  +  " ; " 

"end"] 

] 

builds  imperative-function, 

imperative-function-call  ::=  [  imp-fun-call-identifier 

"("  imp-fun-call-actuals  *","")"] 

builds  imperative-function-call. 


X - 

output  statements 

I - 

imperative-input  ["read"  "("  imp-in-logical-file  "," 

imp-input-list  +  ","  ")"] 

builds  imperative-input, 

imperative-output  ::=  ["write"  "<"  imp-out-logical-file  "," 

imp-output-list  +  ")"] 

builds  imperative-output, 

imperative-format-item  ::=  [imp-fmt-item] 
builds  imperative-format-item, 

imperative-format-item  ::=  [imp-fmt-item  imp-f nt-format] 
builds  imperative-format-item, 

imperative-format-integer  ::=  ["'i"  imp-format-width  ] 
builds  imperative-format-integer, 

imperative-format-integer  ::=  ["'I"  imp-format-width  ] 
print-only, 

imperative-format-decimal  ::=  ["'d"  imp-format-width  imp-decimal-part-width] 

builds  imperative-format-decimal, 

imperative-format-decimal  ::=  [""D"  imp-format-width  imp-decimal-part-width] 

print-only, 

imperative-format-scientific  : :=  [""e"  imp-format-width  ] 
builds  imperative-format-scientific , 
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imperative-format-scientif ic  :  :=  [''*E"  imp-format -width  ] 
print-only, 

imperative-format-string  : :=  [""s"  imp-format-width  ] 
builds  imperative-format-string, 

imperative-format-string  ::=  [""S"  imp-format -width  ] 
print-only 

start-classes  imperative-ast ,  imperative-subprogram 

no-patterns 

precedence 

for  imperative-expression  brackets  "("  matching  ")" 

(same-level  "or"  associativity  left), 

(same-level  "and"  associativity  left), 

(same-level  "not"  associativity  right), 

(same-level  "<",  "<=",  "=",  ">=",  ">",  "/="  associativity  none), 

(same-level  "+",  associativity  left), 

(same-level  "/"  associativity  left), 

(sEime-level  associativity  right) 

end 
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Appendix  B.  The  Generic  Object-Oriented  Language 
B.l  Introduction 

This  appendix  includes  the  surface  syntax  defined  for  the  Generic  Object-Oriented 
Language  (GOL^).  This  surface  syntax  is  not  intended  for  use  as  a  forward-engineering 
programming  language,  but  as  a  user-friendly  interface  to  the  Generic  Object-Oriented 
Model  (GOM)  ASTs.  Instead  of  printing  each  GOM  AST  and  comparing  the  values  of  the 
attributes  of  the  AST,  the  GOL  provides  a  short-hand  view  that  is  used  to  quickly  and 
easily  view  the  attributes  of  a  GOM  AST. 

The  notation  used  to  present  the  surface  syntax  is  taken  from  the  Software  Refinery^^ 
Dialect  tool  [53].  Each  production  for  producing  surface  syntax  is  presented  using  the  fol¬ 
lowing  format: 

<G0M  object>  ::=  [  <surface  syntax  constructs>  ] 

The  left-hand-side  of  this  production  gives  the  GOM  object  for  which  this  surface  syntax 
is  defined,  and  the  right-hand-side  shows  the  sequence  of  constructs  used  to  define  the 
surface  syntax.  This  sequence  can  include  attributes  of  the  object  or  literal  syntax  tokens. 
Optional  constructs  are  enclosed  in  braces,  i.e.  {  }.  Sequences  of  constructs  are  indicated 
by  listing  an  attribute  of  the  object  followed  by  a  star  token  (*)  or  plus  token  (-I-)  followed 
by  the  delimiter  token.  The  star  token  indicates  zero  or  more  members  of  the  sequence 
and  plus  token  indicates  one  or  more  members.  For  example,  the  surface  syntax  for  GOM 
GOM-Variable  objects  is  shown  below. 

GOM-Variable  : :=  [gom-name  ! !  gom-has-indices 
"("  gom-indices  +  ")"  ] 

builds  GOM-Variable, 

This  production  means  the  surface  syntax  for  an  GOM-Variable  is  the  value  of  the 
gom-name  attribute  followed  by  any  indices  in  the  gom-indices  attribute  separated  by 
commas.  The  gom-has-indices  attribute  indicates  whether  or  not  this  variable  access 
includes  indices  into  an  array. 

^Pronounced  “36Z”  as  in  “golf”. 
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B.2  The  Generic  Object-Oriented  Language 


The  productions  that  define  the  GOL  grammar  are  presented  below. 


! !  in-package ( "RU" ) 

!!  in-graitmicir(’ syntax) 

grainmair  Generic-OO-Language 

file-classes  GOM-Design 

productions 

X - 

'/,  overall  design  class 
- 


GOM-Design  ::=  [GOM-classes  +  ""] 
builds  GOM-design, 


•/. - 

'/,  00  objects 

•/. - 


GOM-Class  ::=  ["class"  gom-name 

["attributes"  gom-attrs  ♦ 

[gom-opers  ♦  ""] 

["superclass"  gom-super]] 
builds  GOM-Class, 

GOM-Instantiate  : :=  ["new"  "("  gom-inst-class  ")"] 
builds  GOM-Instantiate, 

GOM-Method  ; :=  ["method"  gom-name  "("  [gom-params  *  ","]  ")" 
" ! !  gom-rtns-val 
"begin" 

[gom-stmts  * 

"end"] 

builds  GOM-Method, 

GOM-Method  ::=  ["method"  gom-name  "("  [gom-params  ♦  ","]  ")" 
! !  gom-rtns-val  " : "  gom-return-type 
"begin" 

[gom-stmts  * 

"end"] 

builds  GOM-Method, 

GOM-Message  ::=  [  gom-call  "("  gom-actuals  *  ")"  ] 

builds  GOM-Message, 


y, - 

'/,  veiriables,  attributes,  and  peirameters 
y - 


295 


GOM-Variable  ::=  [gom-name  "!!  gom-has-indices] 
builds  GOM-Variable, 


GOM-Variable  : : =  [gom-name  ! !  gom-has-indices 
"("  gom-indices  +  ")"  ] 

builds  GOM-Veuriable , 


GOM- Attribute  : [gom-name  "!!  gom-has-indices] 
builds  GOM- Attribute, 


GOM- Attribute  : : =  [gom-name 
"("  gom-indices  + 
builds  GOM-Attribute, 


! !  gom-has-indices 
")"  ] 


GOM-Attr-Access  : :=  [  gom-tar-object  gom-attrib  ] 
builds  GOM-Attr-Access, 

GOM-Pareuneter  ::=  [gom-name  "!!  gom-has-indices] 
builds  GOM-Parameter, 

GOM-Pairameter  ;:=  [gom-name  !!  gom-has-indices 
"("  gom-indices  +  ")"  ] 

builds  GOM-Pareimeter, 


•/. - 

'/,  data  types 

•/. - 


GOM-integer  ["integer"] 
builds  GOM-integer, 

GOM-real  ["real"] 
builds  GOM-real, 

GOM-boolean  :;=  ["boolean"] 
builds  GOM-booleem, 

GOM-character  : :=  ["character"] 
builds  GOM-character, 

GOM-string  ::=  ["string"] 
builds  GOM-string, 

*/,  arrays 

GOM-array  ::=  ["array"  "("  gom-array-dimensions  *  ","  ")" 

"of"  gom-array-element-type  ] 

builds  GOM-array, 

GOM-index-type  : : =  [gom-index-lower-bound  " . . "  gom-index-upper-bound] 
builds  GOM-index-type, 

'/,  instainces 

GOM-instance  ::=  [  "a"  gom-instance-of  ] 
builds  GOM-instemce, 
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X - 

*/,  binary  expressions 
- 


GOH-addition  ::=  [GOM-bin-exp-seq  ++ 
builds  GOM-addition, 

GOM-auid  ::=  [GOM-bin-exp-seq  ++  "and"] 
builds  GOM-and, 

GOM-concat  : : =  [GOM-bin-exp-seq  ++  "ft"] 
builds  GOM-concat, 

GOM-division  ::=  [GOM-bin-exp-seq  ++  "/"] 
builds  GOM-division, 

GOM-equal  ::=  [GOM-bin-exp-operand-1  "="  GOM-bin-exp-operand-2] 
builds  GOM-equal, 

GOM-exponent  ::=  [GOM-bin-exp-operand-l  GOM-bin-exp-operand-2] 
builds  GOM-exponent, 

GOM-greater-them-or-equal  ::=  [GOM-bin-eip-operand-1  ">=" 

GOM-bin-exp-operemd-2] 
builds  GOM-greater-tham-or-equal, 

GOM-greater-than  ::=  [GOM-bin-exp-operand-1  ">"  G0M-bin-exp-oper2Lnd-2] 
builds  GOM-greater-than, 

GOM-less-tham-or-equal  ::=  [GOM-bin-exp-operand-1  "<=" 

GOM-bin-exp-operand-2] 
builds  GOM-less-than-or-equal, 

GOM-less-than  ::=  [GOM-bin-exp-operand-1  "<"  GOM-bin-exp-operand-2] 
builds  GOM-less-than, 

GOM-multiplication  ::=  [GOM-bin-exp-seq  ++  "♦"] 
builds  GOM-multiplication, 

GOM-not-equal  ::=  [GOM-bin-exp-operamd-1  "/="  GOM-bin-exp-operand-2] 
builds  GOM-not-equal, 

GOM-or  : : =  [GOM-bin-exp-seq  ++  "or"] 
builds  GOM-or, 

GOM-subtraction  ::=  [GOM-bin-exp-seq  ++  "-"] 
builds  GOM-subtraction, 


I - 

'/,  wary  expressions 

X - 

GOM-negate  :  :=  ["-"  GOM-wary-operwd] 
builds  GOM-negate, 
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GOM-not  : : =  ["not 
builds  GOM-not, 


GOM-unary-operand] 


GOM-null  ::=  ["  "] 
builds  GOM-null, 

X - 

'/,  literals 

X - 


GOM-literal-true  ::=  "true" 
builds  GOM-literal-true, 

GOM-literal-false  : :=  "false" 
builds  GOM-literal-false, 

GOM-literal-integer  : ;=  GOM-literal-value 
builds  GOM-literal-integer, 

GOM-literal-real  ::=  GOM-literal-value 
builds  GOM-literal-real, 

GOM-literal-charstring  ;:=  GOM-literal-value 
builds  GOM-literal-charstring, 

GOM-literal-newline  ::= 
builds  GOM-literal-newline, 


•/. - 

'/.  assigiunent 

•/. - 


GOM-assignment  [gom-assign-lhs  gom-assign-rhs] 

builds  GOM-assignment, 


•/. - 

'/.  selection 

•/. - 


GOM-selection  ::=  ["if"  gom-exp  "then" 

gom-then-part  + 
"else" 

gom-else-part  + 
"endif "] 

builds  GOM-selection, 


•/. - 

'/,  iteration 

•/. - 


GOM-iteration  : :=  ["while" 


] 

builds  GOM-iteration, 


gom-iter-exp  "do" 
["begin" 

gom-iter-body  +  " 
"end"] 


II 
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I - 

7.  non-user-defined  subprogram  calls 
X - 


GOM-function-call  ::=  [  gom-fun-call-identifier 

"("  gom-f un-call-actuals  *  ")"  ] 

builds  GOM-function-call, 

GOM-procedure-call  : :=  [  gom-proc-call-identifier 

"("  gom-proc-call-actuals  ♦  ")"  ] 

builds  GOM-procedure-call, 

% - 

7,  output  statements 

X - 


GOM-input  ::=  ["read"  "("  gom-in-logical-f ile 

gom-input-list  +  ","  ")"] 

builds  GOM-input, 

GOM-output  ::=  ["write"  "("  gom-out-logical-file  "," 

gom-output-list  +  ","  ")"] 

builds  GOM-output, 


GOM-format-item  ;:=  [gom-f mt-item] 
builds  GOM-format-item, 


GOM-format-item  ::=  [gom-fmt-item  gom-fmt-format] 
builds  GOM-format-item, 

GOM-format-integer  ;:=  [""i"  gom-format-width  ] 
builds  GOM-format-integer, 

GOM-format-integer  : :=  ["*I"  gom-format-width  ] 
print-only, 

GOM-format-decimal  ::=  ["*d"  gom-format-width  gom-decimal-part-width] 
builds  GOM-format-decimal, 


GOM-format-decimal  ::=  [""D"  gom-format-width  gom-decimal-peu:t-width] 
print-only, 

GOM-format-scientific  ::=  [""e"  gom-format-width  ] 
builds  GOM-format-scientific, 


GOM-format-scientific  ::=  [""E"  gom-format-width  ] 
print-only, 

GOM-format-string  ::=  ["*s"  gom-format-width  3 
builds  GOM-format-string, 

GOM-format-string  ::=  [""S"  gom-format-width  ] 
print-only 

start-classes  GOM-Design,  GOM-Class 
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no-patterns 

precedence 

for  GOM-expression  brackets  matching  ")" 

(same-level  "or"  associativity  left), 

(same-level  "and"  associativity  left), 

(same-level  "not"  associativity  right), 

(same-level  associativity  right), 

(sEime-level  "<",  "<=",  "=",  ">=",  ">",  "/="  associativity  none), 

(same-level  "+",  "-"  associativity  left), 

(same-level  "/"  associativity  left), 

(same-level  associativity  left) 

end 
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Appendix  C.  Nested  If  Proof 


Prove: 


wp(if  Bi  then  Si  elsif  B2  then  S2  else  S3,  R) 

wp(if  Bi  then  Si  else  (if  B2  then  S2  else  S3),  R) 


Proof: 


wp(if  Bi  then  Si  elsif  B2  then  S2  else  S3,  R)  -O- 

(Ri  =>  wp(5i,  R))  A 

((-•  Bi  A  B2)  =>  wp(52,  R))  A 
((-1  J5i  A  -1  B2)  wp(53,  R))  ^ 

(Bi  wp(5i,  R))  A 

(-1  (JBi  V  ->  B2)  =>  wp(52,  R))  A 
(-1  (Bi  V  B2)  =J>  wp(53,  R)) 

(Bi  wp(5i,  R))  A 

((Bi  V  -1  B2)  V  wp(52,  R))  A 
((Bi  V  B2)  V  wp(53,  R)) 

(Bi  =»  wp(S'i,  R))  A 

(Bi  V  (-1  B2  V  wp(S2,  R)))  A 
(Bi  V  (B2  V  wp(S3,  R))) 

(Bi  wp(Si,  R))  A 

(Bi  V  ((-.  B2  V  wp(5'2,  R))  A  (B2  V  wp(S3,  R))))  44^ 

(Bi  wp(Si,  R))  A 

(Bi  V  ((B2  =»  wp(S2,  R))  A  (-1  B2  =>  wp(53,  R)))) 

(Bi  =>  wp(Si,  R))  A 

(“’  Bi  ((-B2  ==>  wp(S2,  R))  A  (-.  B2  ==^  wp(S3,  R)))) 

(Bi  =^>  wp(S'i,  R))  A 

(-'  Bi  wp(if  B2  then  S2  else  S3,  R)) 

wp(if  Bi  then  Si  else  (if  B2  then  S2  else  S3),  R) 

Q.E.D. 
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Appendix  D.  Parameter  transformation  Proof 

D.  1  Introduction 

This  appendix  explains  how  to  convert  a  procedure  that  has  at  least  one  parameter 
that  is  both  an  input  parameter  and  an  output  parameter  into  a  procedure  with  parameters 
that  are  either  input  only  or  output  only. 

D.2  New  Procedure  Definition 

Because  of  the  importance  of  the  distinction  between  inpnt  and  output  parameters 
when  converting  the  GIM  to  the  GOM,  parameters  that  are  both  input  and  output  param¬ 
eters  require  special  processing.  A  new  vector  of  output  parameters  is  used  to  represent 
the  “output”  aspect  of  the  input/output  parameters.  The  original  parameters  are  assumed 
to  be  input  only  and  the  new  output  parameters  hold  the  new  values  returned  from  a  pro¬ 
cedure  call.  These  new  values  are  stored  in  the  original  data  items  by  using  an  assignment 
statement  after  the  call  to  the  procedure. 

Let  Pout  represent  the  vector  of  output  parameters  needed  to  represent  the  “output” 
aspect  of  the  input/output  parameters  in  y.  Let  represent  the  precondition  P  with 
all  occurrences  of  the  parameters  in  y  replaced  by  the  parameters  in  Pout-  Let  body^^^^ 
represent  the  body  of  procedure  p,  with  all  occurrences  of  the  parameters  in  y  replaced  by 
the  parameters  in  pout-  Using  these  definitions,  a  new  procedure  p'  is  built  that  accepts 
the  new  output  parameter  pout- 


procedure  p'{x,  y,  pout,  z) 

{P} 


Vout  '• —  V] 


{R} 


The  body  of  p'  includes  as  its  first  statement  an  assignment  statement  to  assign  all 
the  output  parameters  in  pout  the  initial  values  of  p.  All  references  to  p  in  the  original 
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body  of  procedure  p  (and  the  precondition  P)  have  been  replaced  by  references  to  yout  to 
create  the  rest  of  the  body  of  the  procedure  p' . 

If  the  precondition  and  the  postcondition  for  p'  are  the  same  as  the  precondition  and 
the  postcondition  for  p,  then  the  semantics  of  p'  are  the  same  as  that  of  p,  i.e.  the  two 
procedure  definitions  are  equivalent.  The  proof  of  this  is  shown  below. 

Proof.  1.  The  postcondition  R  is  given  as  the  postcondition  for  both  p  and  p'. 

2.  All  references  to  y  are  replaced  by  references  to  pout  both  body  and  P  for  p',  thus 

^Vout  precondition  for  body^^^^. 

3.  wp{yout-=y,  Pt^ut)  =  =  P,  thus  the  precondition  for  p' is  P. 

4.  Since  the  precondition  and  postcondition  are  the  same  for  p  and  p',  the  semantics 
for  these  two  procedure  definitions  are  the  same. 

□ 

D.S  New  Procedure  Call 

Let  bout  represent  a  vector  of  output  parameters  that  represent  the  “output”  aspect 
of  the  input /output  parameters  in  b.  The  invocation  of  the  new  procedure  p'  has  the  form 


p  (a,  6,  bpjif,  c); 

^  bgnf 

The  original  b  parameters  are  used  as  input  only  parameters.  The  new  bout  vector 
holds  the  output  parameters  and  these  new  values  are  stored  back  into  the  b  parameters 
after  the  call  to  p'  using  an  assignment  statement.  Each  call  to  p'  is  now  followed  by  such 
an  assignment  statement. 

Let  body'  represent  the  body  of  statements  from  procedure  p'.  The  execution  of  a 
call  to  procedure  p'  is  equivalent  to 
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X  :=  a; 

y  :=  h 

body*; 

bout  yout't 

c  :=  z; 

This  sequence  clearly  shows  how  the  new  output  parameters  in  bout  set  to  the 
values  in  the  parameters  yout  returned  from  the  procedure  p'. 

Let  P'  represent  the  execution  ofpL  The  semantics  for  this  procedure  call  are  defined 


wp{p'{a,b,b(yut,c),R)  =  wp{^',R) 

The  assignment  statement  following  the  procedure  call  is  required  in  order  to  maintain  the 
semantics  of  the  original  procedure  call.  Thus,  it  is  more  proper  to  define  the  semantics 
for  the  new  form  of  procedure  call  as 

wp{p'{a,  b,  bout,  c);b:=  bout,  R)  =  wp{l3',  wp(b  :=  bout,  R)) 

In  order  to  prove  that  the  addition  of  the  new  vectors  pout  and  bout  is  correct,  it  must 
be  proven  that  the  new  form  of  the  procedure  call  maintains  the  semantics  of  the  original 
procedure  call.  Specifically,  it  must  be  proven  that  the  following  is  true. 

wp{p{a,b,c),R)  ^  wp{p'{d,b,bout,c);  b:=bout,R) 

The  proof  is  shown  below. 
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Proof. 


wp{p{a,  b,  c),R) 

wp{x  :=  a;  y  :=  6;  body,  b  :=  y-,  c  z,  R) 

wp{wp{x  a,  wp{y  :=  b,  wp{body,  wp(b  :=  y,  wp{c  :=  z,  i?)))))) 
wp{x  :=  a;  y  :=  b\  yout  ■=  y;  body^^^^-,  bout  ■=  Vout',  b  :=  bouf,  c  :=  z,  R) 
^  wp{x:=a-,  y:=b-,  body'-,  bout'=yout\  c:=z, 

wp{x  :=  a;  y  :=  6;  body'-,  bout  ■=  Pout;  c  wp(b  :=  bout,  R)) 
wp{p'{a,b,bout,c)-,  b:=bout,R) 


□ 
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Appendix  E.  BMDSIM  Conversion 
Transcript 


grams  from  FORTRAN  to  the  GIM. 

.>  (rfu::test-conversion) 

Not  re-loading  analysis... 

Converting  ”ANG”  to  the  GIM... 

No  side  effects  in  this  function. 

Checking  transformation  completeness... 


Converting  ’’BMDSIMl”  to  the  GIM... 

Warning:  Make  sure  STOP  statement  is 
last  statement  in  main  program 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  2084 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 


This  appendix  shows  the  complete  transcript 
of  the  conversion  of  the  53  BMDSIM  subpro- 


The  transformation  was  complete. 

Total  number  of  tree  nodes:  60 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’ANGLE”  to  the  GIM... 

No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  92 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’ASSIGN”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  wcis  complete. 

Total  number  of  tree  nodes:  609 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 


Converting  ’’BOOSTR”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  338 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’BOSTIT”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  559 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’BOUNCE”  to  the  GIM... 
No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  71 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 


306 


Converting  ’’CAPTURE”  to  the  GIM... 
No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes;  82 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’CROSS”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  86 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ”CSP”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  529 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ”CUV”  to  the  GIM... 

No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  85 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 


Converting  ’’DASET”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  169 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’DOT”  to  the  GIM... 

No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  48 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ”KEP”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes;  102 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ”LASP”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  64 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 
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Converting  ’’LNKCAL”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  703 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’LNKCK”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  178 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’LNKORD”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  316 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’MAT”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  149 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 


Converting  ”MAXA”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  62 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’MIRGEO”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  348 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’MIRVIS”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  357 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ”MTM2”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  65 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 
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Converting  ”MTM3”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  75 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ”MTPD”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  84 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ”MTRT”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  71 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’ORBEL”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  377 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  synteux  in  file 


Converting  ’’PKILL”  to  the  GIM... 

No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  63 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’POSVEC”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  85 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’POSVECS”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  85 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’PRDIV”  to  the  GIM... 

No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  58 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 
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Converting  ’’RADIUS”  to  the  GIM... 

No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  84 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’RAND”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  55 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’RELAY”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  459 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ”RHO”  to  the  GIM... 

No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  22 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 


Converting  ’’RRBVIS”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  419 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’RRPVIS”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  201 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ”RTAN”  to  the  GIM... 

No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  41 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’SBMIT”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  195 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 
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Converting  ’’SBMLOC”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  77 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’SBMPOS”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  167 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’SELECL”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  325 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ”SGN”  to  the  GIM... 

No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  19 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 


Converting  ”SUV”  to  the  GIM... 

No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  80 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  »TFBT”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  94 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’TPANG”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  162 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ”TRAJ”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  217 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 
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Converting  ’’UNIT”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  47 
Number  of  untransformed  nodes;  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntajc  in  file 

Converting  ’’UPLREQ”  to  the  GIM... 
No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  67 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed;  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ’’UPTRNS”  to  the  GIM... 

No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  384 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ”VADD”  to  the  GIM... 
Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  81 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 


Converting  ’’VISCK”  to  the  GIM... 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  164 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed;  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Converting  ”VMAG”  to  the  GIM... 

No  side  effects  in  this  function. 

Checking  transformation  completeness... 

The  transformation  was  complete. 

Total  number  of  tree  nodes:  37 
Number  of  untransformed  nodes:  0 
Percentage  of  AST  transformed:  100.0% 
Saving  to  pob... 

Saving  AST  and  Symbol  Table  in  file 
Saving  surface  syntax  in  file 

Overall  number  of  nodes  in  analysis:  11451.0 
Overall  number  of  untransformed  nodes:  0.0 
Percentage  of  analysis  transformed:  100.0% 
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Appendix  F.  Mapping  GIM  Entities  to  the  GOM 

Figures  207  through  214  show  the  mappings  between  GIM  entities  and  GOM  entities.  The 
transformations  are  shown  in  an  abbreviated  format  where  the  GIM  entity  on  the  left- 
hand-side  of  the  transformation  is  converted  into  the  GOM  entity  on  the  right-hand-side. 
These  transformations  are  straightforward  given  the  description  of  the  GIM  in  Chapter  III 
and  the  description  of  the  GOM  in  Chapter  IV. 


imperative-assignment 

imperative-selection 

imperative-iteration 


gom-assignment 

gom-selection 

gom-iteration 


Figure  207  Control  Flow  Constructs 


imp-subprogram-call  — > 
imperative-function-call  — > 
imp-subprogram-call 
imperative-function-call 


gom-procedure-call 

gom-function-call 

gom-message 

gom-message 


Figure  208  Subprogram  Calls 


imperative- variable  — > 
imperative-name  — > 


gom-variable 

gom-variable 


Figure  209  Data  Storage  Constructs 
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imperative-integer  — »• 
imperative-real  — > 
imperative-boolean  — > 
imperative-character  — 
imperative-string  — > 
imperative-array  — > 
imperative-index-type  — > 


gom-integer 

gom-real 

gom-boolean 

gom-character 

gom-string 

gom-array 

gom-index-type 


Figure  210  Data  Type  Classes 


imperative-literal-boolean  — 
imperative-literal-integer  — > 
imperative-literal-real  — > 
imperative-literal-charstring  — > 
imperative-literal-newline  — ^ 


gom-literal-boolean 

gom-literal-integer 

gom-literal-real 

gom-literal-charstring 

gom-literal-newline 


Figure  211  Literals 
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imperative-addition  — > 
imperative-and  — y 
imperative-concat  — > 
imperative-division  — y 
imperative-equal  — y 
imperative-exponent  — y 
imperative-greater-than-or-equal  — y 
imperative-greater-than  — y 
imperative-less-than-or-equal  — y 
imperative-less-than  — y 
imperative-multiplication  — y 
imperative-not-equal  — > 
imperative-or  — y 
imperative-subtraction  — > 


gom-addition 

gom-and 

gom-concat 

gom-division 

gom-equal 

gom-exponent 

gom-greater-than-or-equal 

gom-greater-than 

gom-less-than-or-equal 

gom-less-than 

gom-multiplication 

gom-not-equal 

gom-or 

gom-subtraction 


Figure  212  Binary  Expressions 


imperative-negate  — »■ 
imperative-not  — > 
imperative-null  — y 


gom-negate 

gom-not 

gom-null 


Figure  213  Unary  Expressions 


imperative-file  — y 
imperative-input  — y 
imperative-output  — y 
imperative-format  — y 


gom-file 

gom-input 

gom-output 

gom-format 


Figure  214  Input  and  Output 


315 


Bibliography 


1.  Achee,  B.L.  and  Doris  L.  Carver.  “A  Greedy  Approach  to  Object  Indentification  in 
Imperative  Code.”  3rd  Workshop  on  Program  Comprehension.  4-11.  November  1994. 
7  May  97. 

2.  Aho,  Alfred  V.,  et  al.  Compilers:  Principles,  Techniques,  and  Tools  (2nd  Edition). 
Reading,  MA:  Addison  Wesley,  1988. 

3.  Barnes,  J.  G.  R  Programming  in  Ada.  Wokingham,  England:  Addison- Wesley,  1994. 

4.  Biggerstaff,  T.  J.,  et  al.  “Program  Understanding  and  the  Concept  Assignment  Prob¬ 
lem,”  Communications  of  the  ACM,  57(5):72-82  (May  1994). 

5.  Biggerstaff,  Ted  J.  “Design  Recovery  for  Maintenance  and  Reuse,”  IEEE  Computer, 
36-49  (Jul  1989). 

6.  Biggerstaff,  Ted  J.,  et  al.  “The  Concept  Assignment  Problem  in  Program  Understand¬ 
ing.”  Proceedings  of  the  15th  International  Conference  on  Software  Engineering,  edited 
by  Edna  Straub.  483-498.  Los  Alamitos,  CA:  IEEE  Computer  Society  Press,  May 
17-21  1993. 

7.  Blaha,  Michael  and  William  Premerlani.  “A  Catalog  of  Object  Model  Transforma¬ 
tions.”  Proceedings  of  the  Third  Working  Conference  on  Reverse  Engineering.  87-96. 
Nov  1996. 

8.  Boehm,  Barry  W,  Software  Engineering  Economics.  Prentice  Hall,  1981. 

9.  Booch,  Grady.  Object-Oriented  Analysis  and  Design  (2nd  Edition).  Redwood  City, 
CA:  The  Benjamin/Cummings  Publishing  Company,  Inc.,  1994. 

10.  Booch,  Grady  and  James  Rumbaugh.  Unified  Method  (0.8  Edition).  Rational  Software 
Corporation,  280  San  Tomas  Expressway,  1995. 

11.  Budd,  Timothy.  Object-Oriented  Programming.  Reading,  MA:  Addison- Wesley,  1991. 

12.  Byrne,  Eric  J.  “A  conceptual  foundation  for  software  re-engineering.”  Proceedings  of 
the  International  Conference  on  Software  Maintenance.  216-235.  IEEE  Computer 
Society  Press,  Nov  1992. 

13.  Chikofsky,  Elliot  and  James  Cross.  “Reverse  Engineering  and  Design  Recovery:  A 
Taxonomy,”  IEEE  Software,  7(1):13-17  (Jan  1990). 

14.  Choi,  Song  C.  and  Walt  Scacchi.  “Extracting  and  Restructuring  the  Design  of  Large 
Systems,”  IEEE  Software,  7(1):66-71  (Jan  1990). 

15.  DeLoach,  Scott.  Appendix  A:  Generic  OMT  Abstract  Syntax  Tree.  PhD  dissertation. 
Air  Force  Institute  of  Technology,  Dayton,  OH,  Jun  1995. 

16.  Dershem,  Herbert  L.  and  Michael  J  dipping.  Programming  Languages:  Structures  and 
Models.  Boston,  MA:  PWS  Publishing  Co,  1993. 


316 


17.  Detienne,  F.  and  E.  Soloway.  “An  Empirically-Derive  Control  Struture  for  the  Pro¬ 
cess  of  Program  Understanding,”  International  Journal  of  Man-Machine  Studies, 
55(3):323-342  (1990). 

18.  Dijkstra,  E.  W.  A  Discipline  of  Programming.  Prentice-Hall,  1976. 

19.  Dromey,  Geoff.  Program  Derivation:  The  Development  of  Programs  from  Specifica¬ 
tions.  Sydney,  Australia:  Addison  Wesley,  1989. 

20.  Ferrante,  J.,  et  al.  “The  Program  Dependence  Graph  and  Its  Use  in  Optimization,” 
ACM  Transactions  on  Programming  Languages  and  Systems,  P(3):319-349  (Jul  1987). 

21.  Gall,  Harald  and  Rene  Klosch.  “Finding  Objects  in  Procedural  Programs:  An  Alter¬ 
native  Approach.”  In  Wills  et  al.  [78],  208-216. 

22.  Gallagher,  Keith  B.  and  James  R.  Lyle.  “Using  Program  Slicing  in  Software  Mainte¬ 
nance,”  Transactions  on  Software  Engineering,  77(8):751-761  (Aug  1991). 

23.  Ghezzi,  Carlo  and  Mehdi  Jazayeri.  Programming  Language  Concepts.  New  York:  John 
Wiley  and  Sons,  1982. 

24.  Grassman,  Winfried  Karl  and  Jean-Paul  Tremblay.  Logic  and  Discrete  Mathematics. 
Upper  Saddle  River,  New  Jersey:  Prentice  Hall,  1996. 

25.  Gries,  David.  The  Science  of  Programming.  Springer- Verlag,  1981. 

26.  Harandi,  Mehdi  T.  and  Jim  Q.  Ning.  “Knowledge-Based  Program  Analysis,”  IEEE 
Software,  7(1):74-81  (Jan  1990). 

27.  Harris,  David  R.,  et  al.  “Recognizers  for  Extracting  Architectural  Features  from  Source 
Code.”  In  Wills  et  al.  [78],  252-261. 

28.  Hartman,  John.  Automatic  Control  Understanding  for  Natural  Programs.  PhD  disser¬ 
tation,  University  of  Texas  at  Austin,  Technical  Report  Al  91-161,  1991. 

29.  Hausler,  Philip  A.  and  Mark  G.  Pleszkoch.  “Using  Function  Abstraction  to  Understand 
Program  Behavior,”  IEEE  Software,  7(l):55-63  (Jan  1990). 

30.  Horwitz,  S.,  et  al.  “Interprocedural  Slicing  Using  Dependence  Graphs.”  Proceedings 
of  the  ACM  SIGPLAN  88,  Conference  on  Programming  Language  Design  and  Imple¬ 
mentation.  35-46.  Jun  1988. 

31.  Hutchens,  D.  H.  and  V.  R.  Basili.  “System  Structure  Analysis:  Clustering  with 
Data  Bindings,”  IEEE  Transactions  on  Software  Engineering,  (8):749-757  (Aug 
1985). 

32.  Jacobson,  Ivar.  Object-Oriented  Software  Engineering.  Wokingham,  England: 
Addison- Wesley,  1992. 

33.  Jacobson,  Ivar  and  Fredrik  Lindstrom.  “Re-engineering  Old  Systems  to  an  Object- 
Oriented  Architecture.”  OOPSLA  Proceedings.  340-350.  1991. 

34.  Johnson,  W.  Lewis  and  Ali  Erdem.  “Interactive  Explanation  of  Software  Systems.” 
Proceedings  of  the  10th  Knowledge-Based  Software  Engineering  Conference.  1995. 


317 


35.  Kernighan,  Brian  W.  and  Dennis  M.  Ritchie.  The  C  Programming  Language.  Prentice 
Hall,  1988. 

36.  Kirkpatrick,  Wally.  A  Method  for  Improving  Technology  Research  and  Develop¬ 
ment  Decisions  Regarding  BMD  and  AS  AT.  DESE  Research  and  Engineering,  Inc., 
Huntsville,  AL,  July  1985.  14  July  97. 

37.  Knuth,  Donald  E.  “Structured  Programming  with  go  to  Statements,”  Computing 
Surveys,  (J(4):262-301  (Dec  1974). 

38.  Korson,  Tim  and  John  D.  McGregor.  “Object-Oriented:  A  Unifying  Paradigm,”  Com¬ 
munications  of  the  ACM,  55(9):40-60  (Sep  1990). 

39.  Kozaczynski,  W.,  et  al.  “Program  Concept  Recognition  and  Transformation,”  Trans¬ 
actions  of  Software  Engineering,  J5(12):1065-1075  (Dec  1992). 

40.  Letovsky,  S.  and  E.  Soloway.  “Delocalized  Plans  and  Program  Comprehension,”  IEEE 
Software,  5(3):41-48  (May  1986). 

41.  Letovsky,  Stanley.  Plan  analysis  of  programs.  PhD  dissertation,  Yale  University,  Dec 
1988. 

42.  Liu,  S.  S.  and  N.  Wilde.  “Identifying  Objects  in  a  Conventional  Procedural  Language: 
An  Example  of  Data  Design  Recovery.”  Proceedings  of  the  Conference  on  Software 
Maintenance.  266-271.  Nov  1990. 

43.  Livadas,  Panos  E.  and  Theodore  Johnson.  A  New  Approach  to  Finding  Objects  in 
Programs.  Technical  Report  SERC-TR-63-F,  University  of  Florida,  Jun  1993. 

44.  Lowry,  Michael  R.  and  Robert  D.  McCartney,  editors.  Automating  Software  Design, 
1.  Menlo  Park,  CA:  AAAI  Press  /  The  MIT  Press,  1991. 

45.  Lutsky,  Patricia.  “Automating  Testing  by  Reverse  Engineering  of  Software  Documen¬ 
tation.”  In  Wills  et  al.  [78],  8-12. 

46.  MacLane,  Saunders  and  Garrett  Birkhoff.  Algebra  (Third  Edition).  New  York,  NY: 
Chelsea  Publishing  Company,  1993. 

47.  Newcomb,  Phillip.  “Re-engineering  Procedural  into  Object-Oriented  Systems.”  In 
Wills  et  al.  [78],  237-251. 

48.  Ning,  J.  Q.,  et  al.  “Automated  Support  for  Legacy  Code  Understanding,”  Communi¬ 
cations  of  the  ACM,  57(5):50-57  (May  1994). 

49.  Olsem,  Michael  R.  and  Chris  Sittenauer.  Reengineering  Technology  Report.  Technical 
Report  Vol  1,  Hill  AFB,  UT:  Software  Technology  Support  Center,  Aug  1993.  17  Jul 
97. 

50.  Ong,  C.  L.  and  W.  T.  Tsai.  “Class  and  Object  Extraction  from  Imperative  Code,” 
Journal  of  Object-Oriented  Programming,  ^(l):58-68  (Mar  1993). 

51.  Quilici,  Alex.  “A  Memory-Based  Approach  to  Recognizing  Programming  Plans,”  Com¬ 
munications  of  the  ACM,  57(5):84-93  (May  1994). 


318 


52.  Quilici,  Alex  and  David  N.  Chin.  “DECODE:  A  Cooperative  Environment  for  Reverse- 
Engineering  Legacy  Software.”  In  Wills  et  al.  [78],  156-165. 

53.  Reasoning  Systems  Inc,  Palo  Alto,  CA.  DIALECT  User’s  Guide,  July  1989. 

54.  Reasoning  Systems  Inc,  Palo  Alto,  CA.  REFINE  User’s  Guide,  May  1990. 

55.  Reasoning  Systems  Inc,  Palo  Alto,  CA.  REFINE/FORTRAN  User’s  Guide,  March 
1994. 

56.  Reubenstein,  Howard  B.  and  Richard  C.  Waters.  “The  Requirements  Apprentice: 
Automated  Assistance  for  Requirements  Acquisition,”  IEEE  Trans  on  Software  Engi¬ 
neering,  J7(3):226-240  (Mar  1991). 

57.  Rich,  Charles.  “A  Formal  Representation  for  Plans  in  the  Programmer’s  Apprentice.” 
Proceedings  of  the  7th  International  Joint  Conference  on  Artificial  Intelligence,  edited 
by  Michael  L.  Brodie,  et  al.  1044-1052.  New  York:  Springer- Verlag,  Aug  1981. 

58.  Rich,  Charles  and  Yishai  A.  Feldman.  “Seven  Layers  of  Knowledge  Representation 
and  Reasoning  in  Support  of  Software  Development,”  IEEE  Trans  on  Software  Engi¬ 
neering,  J5(6):451-469  (Jun  1992). 

59.  Rich,  Charles  and  Richard  Waters.  “The  Programmer’s  Apprentice:  A  Research 
Overview,”  IEEE  Computer,  10-25  (Nov  1988). 

60.  Rich,  Charles  and  Linda  M.  Wills.  “Recognizing  a  Program’s  Design:  A  Graph-Parsing 
Approach,”  IEEE  Software,  7(l):82-89  (Jan  1990). 

61.  Rugaber,  Spencer.  White  Paper  on  Reverse  Engineering.  Technical  Report,  Atlanta, 
GA:  Georgia  Institute  of  Technology,  Mar  1994. 

62.  Rumbaugh,  James  and  Michael  Blaha.  Object-Oriented  Modeling  and  Design.  New 
Jersey:  Prentice-Hall,  Inc.,  1991. 

63.  Shlaer,  S.  and  S.  J.  Mellor.  Object  Lifecycles  -  Modeling  the  World  in  States.  Engle¬ 
wood,  Cliffs:  Yourdon  Press,  1992. 

64.  Shooman,  Martin  L.  Software  Engineering.  McGraw  Hill  Book  Company,  1983. 

65.  Smith,  Douglas  R.  “KIDS:  A  Semiautomatic  Program  Development  System,”  IEEE 
Transactions  on  Software  Engineering,  76(9):1024-1043  (Sep  1990). 

66.  Smith,  Douglas  R.  Classification  Approach  to  Design.  Technical  Report  KES.U.93.4, 
3260  Hillview  Ave:  Kestrel  Institute,  Nov  1993. 

67.  Sneed,  H.  “Migration  of  Procedurally  Oriented  COBOL  Programs  in  an  Object- 
Oriented  Architecture.”  Proceedings  of  the  Conference  on  Software  Maintenance.  105- 
116.  Nov  1992. 

68.  Sneed,  Harry  M.  and  Erika  Nyary.  “Extracting  Object-Oriented  Specifications  from 
Procedurally  Oriented  Programs.”  In  Wills  et  al.  [78],  217-226. 

69.  Soloway,  E.  and  K.  Erdlich.  “Empirical  Studies  of  Programming  Knowledge,”  IEEE 
Transactions  on  Software  Engineering,  i(?(5):595-609  (1984). 


319 


70.  Soloway,  Elliot  and  W.  Lewis  Johnson.  “PROUST:  Knowledge-Based  Program  Un¬ 
derstanding,”  IEEE  Transactions  on  Software  Engineering,  SE-11  {3):2&7-275  (Mar 
1985). 

71.  Stroustrup,  Bjarne.  The  C++  Programming  Language.  ATT  Bell  Labs,  New  Jersey, 
Jul  1987. 

72.  Tennent,  R.  D.  Principles  of  Programming  Languages .  New  York:  Prentice-Hall,  1981. 

73.  Tiemens,  Tim.  Cognitive  Models  of  Program  Comprehension.  Technical  Report,  Soft¬ 
ware  Engineering  Research  Center,  Georgia  Tech,  Dec  1989. 

74.  Waters,  Richard  C.  “The  Programmer’s  Apprentice:  A  Session  with  KBEmacs,”  IEEE 
Transaction  on  Software  Engineering,  JJ(11):1296-1320  (Nov  1981). 

75.  Waters,  Richard  C.  “Program  Translation  via  Abstraction  and  Reimplementation,” 
IEEE  Transactions  on  Software  Engineering,  7.^(8):1207-1228  (Aug  1988). 

76.  Weiser,  M.  “Program  Slicing,”  IEEE  Transactions  on  Software  Engineering,  SE- 
i0(4):352-357  (Jul  1984). 

77.  Wilde,  N.,  et  al.  “Dependency  Analysis  Tools:  Reusable  Components  for  Software 
Maintenance.”  Proceedings  of  the  Conference  on  Software  Maintenance.  126-131.  Oct 
1989. 

78.  Wills,  Linda,  et  al.,  editors.  Second  Working  Conference  on  Reverse  Engineering,  Los 
Alamitos,  CA:  IEEE  Computer  Society  Press,  Jul  1995. 

79.  Yeh,  Alexander  S.,  et  al.  “Recovering  Abstract  Data  Types  and  Object  Instances  from 
a  Conventional  Procedural  Language.”  In  Wills  et  al.  [78],  227-236. 


320 


Vita 


the  Salnl.atorinri  of  r.;yimville-Sully  High  School  in  May  1981.  In  Mciy  1985  he  received 
a  H.aclielor  of  Science  degree  in  CoriiputjT  ficience  Horn  Iowa  State  Univt^rsity.  Major 
Sward  wiis  a  Distinguished  Graduate  of  tlie  Iowa  State  University  ROTC  program.  His 
iiist  assignment  was  to  the  Missile  Warning  Direct.oratc  at  HQ  Strategic.  Air  Connnand 
in  Omaha,  NE.  While  in  Omaha, 

Major  Sward  was  lium  selected  to  attend  an  AFIT/CI  d(?gree  program  at  the  University 
of  Colorado.,  Bcjulder,  He  received  a  Master  of  Science  degree  in  Information  Systems  and 
a  Master  of  Science  degree  in  Computer  Science  in  Jul  1991.  Ma  jor  Sward  was  assigned  to 
the  USAF  Academy  as  an  Instructor  in  the  Computer  Science  deijarl.inent.  In  May  1994 
Major  Sward  received  the  Outiitanding  Academy  Educator  award,  which  i.s  given  to  thi5  toj) 
instructor  in  each  department,  In  Sep  1994,  Major  Sward  reported  to  Wright-Patterson 
.-\FB  ilo  enter  the  PhD  program.  Upon  graduation,  Major  Sward  will  return  to  the  USAF 
Academy  as:  an  Assistant  Profes.sor  in  the  Computer  Science  department, 


REPORT  DOCUMENTATION  PAGE 

Form  Approved 

0MB  No.  0704-0188 

Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources, 
gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this 
collection  of  information,  including  suggestions  for  reducing  this  burden,  to  \Afa^ington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson 
Davis  Highway,  Suite  1 204,  Arlington,  VA  22202-4302,  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188),  Washington,  DC  20503. 

1.  AGENCY  USE  ONLY  rieave  Wan«  2.  REPORT  DATE  3.  REPORT  TYPE  AND  DATES  COVERED 

September  1997  Doctoral  Dissertation 

4.  TITLE  AND  SUBTITLE 

Extracting  Functionally  Equivalent  Object-Oriented  Designs  from  Legacy  Imperative 
Code. 

5.  FUNDING  NUMBERS 

6.  AUTHOR(S) 

Ricky  E.  Sward,  Major,  USAF 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Air  Force  Institute  of  Technology 

2750  P  St 

WPAFB,  OH  45433-7765 

8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 

AFIT/DS/ENG/97-04 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

Mr  Douglas  A.  White 

Rome  Lab/C3CB 

525  Brooks  St 

Rome,  NY  13441-4505 

10.  SPONSORING/MONITORING 

AGENCY  REPORT  NUMBER 

11.  SUPPLEMENTARY  NOTES 

12a.  DISTRIBUTION  AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

12b.  DISTRIBUTION  CODE 

13.  ABSTRACT  (Maximum  200  words) 

This  research  defines  a  methodology  for  automatically  extracting  functionally  equivalent  object-oriented  designs  from 
legacy  imperative  programs.  The  Parameter-Based  Object  Identification  (PBOI)  methodology  is  based  on  fundamental 
ideas  that  relate  programs  written  in  imperative  languages  such  as  C  or  COBOL  to  objects  and  classes  written  in 
object-oriented  languages  such  as  Ada  95  or  C  +  + .  Transformations  have  been  developed  that  formalize  the  PBOI 
methodology  and  a  formal  proof  is  provided  showing  the  extracted  object-oriented  design  is  functionally  equivalent  to  the 
legacy  imperative  system.  To  focus  the  task  of  re-engineering,  generic  models  of  imperative  programming  languages  and 
object-oriented  programming  languages  have  been  developed.  The  formal  transformations  convert  imperative  subprograms 
represented  in  the  Generic  Imperative  Model  (GIM)  into  classes  and  objects  represented  in  the  Generic  Object-Oriented 
Design  Model  (GOM).  A  taxonomy  of  imperative  subprograms  has  also  been  developed  which  classifies  all  imperative 
subprograms  into  one  of  six  categories.  A  proof-of-concept  prototype  has  been  developed  and  a  3000-line  FORTRAN-77 
system  has  been  converted  to  an  object-oriented  design  as  a  feasibility  demonstration. 

14.  SUBJECT  TERMS 

reverse  engineering,  re-engineering,  formal  transformations,  formal  proofs,  object-oriented 
design,  imperative  programming  languages,  object-oriented  programming  languages,  software 
engineering 

15.  NUMBER  OF  PAGES 

345 

16.  PRICE  CODE 

17.  SECURITY  CLASSIFICATION 
OF  REPORT 

UNCLASSIFIED 

18.  SECURITY  CLASSIFICATION 
OF  THIS  PAGE 

UNCLASSIFIED 

19.  SECURITY  CLASSIFICATION 
OF  ABSTRACT 

UNCLASSIFIED 

20.  LIMITATION  OF  ABSTRACT 

UL 

Standard  Form  298  (Rev.  2-89)  (EG) 

Prescribed  by  ANSI  Std.  239.18 

Designed  using  Perforn)  Pro,  WHS/DIOR,  Oct  94 


